, Простой пример

Ошибки, связанные с межсайтовым скриптингом (Cross site scripting, XSS), являются достаточно известными, но по-прежнему исключительно опасными. Их уникальность заключается в том, что вместо непосредственной атаки сервера, они используют уязвимый сервер в качестве средства атаки на клиента. Это может сделать исключительно трудным отслеживание подобных атак, особенно если запросы не полностью протоколиуются (как в случае POST-запросов)

XSS-атака обычно проводится путем конструирования специального URL, который атакующий подсовывает своей жертве. Можно провести аналогию между XSS-атакой и переполнением буфера, и между встраиванием скрипта и переписыванием EIP. В обоих случаях существуют две возможности для совершения успешной атаки: вставка мусора, либо переход в другую точку. Вставка мусора при переполнении буфера обычно приводит к атаке на отказ в обслуживании. В случае XSS-атаки она позволяет атакующему отобразить произвольную информацию и подавить вывод оригинальной веб-странице. Что касается перехода в другую точку, при переполнении буфера он обычно производится в некоторую область памяти, в которой расположен код, позволяющий захватить контроль над исполнение программы. В случае XSS, атакующий перенаправляет жертву на некоторую веб-страницу (как правило, находящуюся под контролем атакующего), перехватывая текущую сессию.

Но каким образом осуществляются XSS-атаки? Они становятся возможными из-за ошибок в серверных приложениях, и корни их - в пользовательском вводе, который некорректно очищен от HTML-кода. Если атакующий получит возможность вставить произвольный HTML-код, то он сможет управлять отображением веб-страницы с правами самого сайта. Простейшая страница, уязвимая к подобным атакам, выглядит так:

При открытии страницы, переменная name, отправляемая методом GET, выводится непосредственно в ее теле, со всеми метасимволами. Передав в качестве параметра "Cool Hacker", мы получим корректный вариант отображения.

Передав в параметре HTML-код, можно добиться неожиданного результата:

Ввод не проверяется серверным скриптом перед тем как передать результат броузеру, и это позволяет вставить в уязвимую страницу произвольный пользовательский код. Иногда пользовательский ввод не обрабатывается скриптом непосредственно, а вставляется в файл или базу данных, и после этого забирается оттуда для вставки в страницу.

Традиционным местом для XSS-ошибок являются страницы, выводящие всевозможные подтверждения (например, поисковые скрипты дублируют пользовательский ввод перед результатами поиска), и страницы с сообщениями об ошибках, сообщающие пользователю, что именно он ввел не так. В последнем случае (а иногда и в первом) для атаки часто достаточно закрыть содержимое текстового поля символами "> - кавычка закрывает параметр value, а > - весь тег.

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

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