Авторы: Джейкоб Каллин и Ирен Лобо Валбуэна (Jakob Kallin, Irene Lobo Valbuena)
Оригинал статьи
Перевод: Ольга Алифанова

Руководство по XSS, часть 1

Это вторая часть руководства по XSS. В первой части была дана общая информация по XSS-уязвимостям и основному сценарию их использования.

Типы XSS

Несмотря на то, что цель XSS-атаки всегда в том, чтобы запустить вредоносный JavaScript в браузере жертвы, способы, которыми этого можно добиться, фундаментально различаются. XSS-атаки часто делят на три типа:

• Длительная XSS-атака, когда вредоносная строка хранится в базе данных сайта.
• Отраженная XSS-атака, когда вредоносная строка создается в запросе жертвы.
• Основанная на DOM атака, когда уязвимость находится в клиентском коде, а не в серверном.

Пример в первой части иллюстрировал длительную XSS-атаку. Теперь мы опишем два оставшихся типа атак: отраженную и основанную на DOM.

Отраженная XSS

При отраженной XSS-атаке вредоносная строка – это часть запроса жертвы к сайту. Сайт затем включает эту строку в отправленный пользователю ответ. Иллюстрация – на диаграмме ниже.

1. Злоумышленник создает URL, содержащий вредоносную строку, и отправляет ее жертве.
2. Жертва обманута злоумышленником и запрашивает URL с сайта.
3. Сайт включает вредоносную строку в свой ответ.
4. Браузер жертвы выполняет вредоносный скрипт из ответа, пересылая куки жертвы на сервер злоумышленника.

В каких случаях отраженная XSS-атака будет успешной?

Поначалу отраженная XSS кажется безобидной – для ее успеха необходимо, чтобы жертва самостоятельно отправила запрос, содержащий вредоносный код. Так как никто добровольно не выстрелит себе в ногу, казалось бы, выполнение такой атаки невозможно.

Как оказывается, есть минимум два распространенных способа заставить жертву запустить отраженную XSS-атаку против себя же:

• Если цель – конкретный человек, злоумышленник может отправить ему вредоносный URL (через почту или чат), и обманом заставить посетить его.
• Если цель – группа людей, злоумышленник может опубликовать ссылку на вредоносный URL (на своем сайте или в социальной сети), и подождать, пока кто-нибудь на нее нажмет!

Два этих метода схожи, и более успешны при использовании сервисов, сокращающих URL – они маскируют вредоносную строку от пользователей, которые в прочих случаях опознали бы ее.

XSS-атака, основанная на DOM

Основанная на DOM XSS-атака – это вариация на тему как долговременной, так и отраженной атак. При основанной на DOM XSS вредоносная строка не обрабатывается браузером жертвы, пока не выполнен добропорядочный JavaScript сайта. Сценарий отраженной XSS показан ниже:

1. Злоумышленник создает URL, содержащий вредоносную строку, и отправляет ее жертве.
2. Жертва, введенная злоумышленником в заблуждение, запрашивает URL с сайта.
3. Сайт получает запрос, но не включает вредоносную строку в свой ответ.
4. Браузер жертвы выполняет легальный скрипт из ответа, заставляя вредоносный скрипт встроиться в страницу.
5. Браузер жертвы выполняет вредоносный скрипт на странице, отправляя куки жертвы на сервер злоумышленника.

Чем отличаются XSS на основе DOM

В предыдущих примерах долговременных и отраженных XSS-атак сервер вставлял вредоносный скрипт в страницу, которая затем отправлялась пользователю в ответе. Когда браузер жертвы получал ответ, он полагал, что вредоносный скрипт – часть легального содержимого страницы, и автоматически запускал его в ходе загрузки страницы, как и все остальные скрипты.

В ситуации с XSS на основе DOM вредоносный скрипт как часть страницы отсутствует; единственные автоматически запускающиеся во время загрузки страницы скрипты – это ее легальное содержание. Проблема в том, что этот легальный скрипт напрямую использует пользовательский ввод, чтобы добавить HTML на страницу. Так как вредоносный скрипт встраивается в страницу через innerHTML, он воспринимается как HTML, и в результате вредоносный скрипт запускается.

Разница тут тонкая, но важная:

• При традиционных XSS вредоносный JavaScript запускается, когда загружается страница, как часть отправленного сервером HTML.
• При XSS на основе DOM вредоносный JavaScript выполняется после загрузки страницы, как результат небезопасного обращения легального JavaScript этой страницы с пользовательским вводом.

Почему XSS на основе DOM опасны

В предыдущем примере JavaScript не был необходим, сервер мог сгенерировать весь HTML самостоятельно. Если в серверном коде нет уязвимостей, сайт был бы защищен от XSS.

Однако с ростом продвинутости веб-приложений все больше HTML генерируется через JavaScript на клиентской, а не на серверной стороне. Если контент нужно обновить без перезагрузки всей страницы, то такое обновление выполняется через JavaScript. Наиболее значимый пример – обновление страницы после AJAX-запроса.

Это означает, что XSS-уязвимости могут присутствовать не только в серверной части кода вашего приложения, но и в клиентском JavaScript-коде. Следовательно, даже при наличии полностью защищенного серверного кода клиентский код все еще может небезопасно включать пользовательский ввод в DOM-обновление после загрузки страницы. Если это произойдет, клиентский код позволит осуществить XSS-атаку, а серверный код будет ни при чем.

Невидимая для сервера XSS на основе DOM

Есть отдельный случай XSS на основе DOM, при котором вредоносная строка никогда не отправляется на сервер сайта: это случай, когда она содержится в идентификаторе фрагмента URL (все после символа #). Браузеры не отправляют эту часть URL на серверы, поэтому сайт не может получить к ней доступ при помощи серверного кода. Клиентский код меж тем имеет к ней доступ и может быть уязвим для XSS, обращаясь с этой частью URL небезопасно.

Эта ситуация не ограничена идентификаторами фрагментов. Прочий пользовательский ввод, невидимый для сервера, включает новые возможности HTML5 – например, LocalStorage и IndexedDB.

В заключительной части руководства мы поговорим о том, как предотвратить XSS-уязвимости.

Обсудить статью в форуме