Руководство по XSS, часть 2 |
13.01.2020 00:00 |
Авторы: Джейкоб Каллин и Ирен Лобо Валбуэна (Jakob Kallin, Irene Lobo Valbuena) Это вторая часть руководства по XSS. В первой части была дана общая информация по XSS-уязвимостям и основному сценарию их использования. Типы XSSНесмотря на то, что цель XSS-атаки всегда в том, чтобы запустить вредоносный JavaScript в браузере жертвы, способы, которыми этого можно добиться, фундаментально различаются. XSS-атаки часто делят на три типа:
Пример в первой части иллюстрировал длительную XSS-атаку. Теперь мы опишем два оставшихся типа атак: отраженную и основанную на DOM. Отраженная XSS При отраженной XSS-атаке вредоносная строка – это часть запроса жертвы к сайту. Сайт затем включает эту строку в отправленный пользователю ответ. Иллюстрация – на диаграмме ниже.
В каких случаях отраженная XSS-атака будет успешной? Поначалу отраженная XSS кажется безобидной – для ее успеха необходимо, чтобы жертва самостоятельно отправила запрос, содержащий вредоносный код. Так как никто добровольно не выстрелит себе в ногу, казалось бы, выполнение такой атаки невозможно. Как оказывается, есть минимум два распространенных способа заставить жертву запустить отраженную XSS-атаку против себя же:
Два этих метода схожи, и более успешны при использовании сервисов, сокращающих URL – они маскируют вредоносную строку от пользователей, которые в прочих случаях опознали бы ее. XSS-атака, основанная на DOM Основанная на DOM XSS-атака – это вариация на тему как долговременной, так и отраженной атак. При основанной на DOM XSS вредоносная строка не обрабатывается браузером жертвы, пока не выполнен добропорядочный JavaScript сайта. Сценарий отраженной XSS показан ниже:
Чем отличаются XSS на основе DOM В предыдущих примерах долговременных и отраженных XSS-атак сервер вставлял вредоносный скрипт в страницу, которая затем отправлялась пользователю в ответе. Когда браузер жертвы получал ответ, он полагал, что вредоносный скрипт – часть легального содержимого страницы, и автоматически запускал его в ходе загрузки страницы, как и все остальные скрипты. В ситуации с XSS на основе DOM вредоносный скрипт как часть страницы отсутствует; единственные автоматически запускающиеся во время загрузки страницы скрипты – это ее легальное содержание. Проблема в том, что этот легальный скрипт напрямую использует пользовательский ввод, чтобы добавить HTML на страницу. Так как вредоносный скрипт встраивается в страницу через innerHTML, он воспринимается как HTML, и в результате вредоносный скрипт запускается. Разница тут тонкая, но важная:
Почему 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-уязвимости. |