Что такое XSS
Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении кода, исполняемого на стороне клиента (JavaScript) в веб-страницу, которую просматривают другие пользователи.
Уязвимость возникает из-за недостаточной фильтрации данных, которые пользователь отправляет для вставки в веб-страницу. Намного проще понять на конкретном пример. Вспомните любую гостевую книгу – это программы, которые предназначены для принятия данных от пользователя и последующего их отображения. Представим себе, что гостевая книга никак не проверяет и не фильтрует вводимые данные, а просто их отображает.
Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP – этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке:
Если кто-то из пользователей ввёл:
Привет! Нравится твой сайт.
То веб-страница отобразит:
Привет! Нравится твой сайт.
А если пользователь введёт так:
Привет! Нравится твой сайт.<script>alert("Pwned")</script>
То отобразиться это так:
Браузеры хранят множества кукиз большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.
Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.
Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта.
Внедрённый код умеет всё то, что умеет JavaScript, а именно:
<script>alert(document.cookie)</script>
На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.
Виды XSS
Самое главное, что нужно понимать про виды XSS то, что они бывают:
Особенности XSS основанных на DOM
Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:
"/><script>alert(1)</script>
А при открытии исходного HTML кода мы видим что-то вроде такого:
<div class="m__search">
<form method="get" action="/search.php">
<input type="text" class="ui-input query" name="q" value=""/><script>alert(1)</script>" /> <button type="submit" class="ui-button">Найти</button>
</form>
А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:
<!DOCTYPE html>
<html>
<head>
<title>HackWare.ru::
OM XSS</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div id="default"> An error occurred...</div>
<script>
function OnLoad() {
var foundFrag = get_fragment();
return foundFrag;
}
function get_fragment() {
var r4c = '(.*?)';
var results = location.hash.match('.*input=token(' + r4c + ');');
if (results) {
document.getElementById("default").innerHTML = "";
return (unescape(results[2]));
} else {
return null;
}
}
display_session = OnLoad();
document.write("Your session ID was: " + display_session + "<br><br>")
</script>
</body>
</html>
Если мы перейдём по примерно такой ссылке
То в браузере мы увидим:
Исходный код страницы:
Давайте сформируем адрес следующим образом:
<script>alert(1)</script>;
Теперь страница выглядит так:
Но давайте заглянем в исходный код HTML:
Там совершенно ничего не изменилось. Про это я и говорил, нам нужно смотреть DOM структуру документа, чтобы выявить злонамеренный код:
Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:
<script>alert(1)%3balert(2)</script>;
Где мы заменили символ ; на кодированный в URI эквивалент!
Теперь мы можем написать вредоносную полезную нагрузку JavaScript и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга.
XSS Auditor
В Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз:
Т.е. теперь в браузере есть XSS аудитор, который будет пытаться предотвращать XSS. В Firefox ещё нет такой функциональности, но, думаю, это дело времени. Если реализация в браузерах будет удачной, то можно говорить о значительном затруднении применения XSS.
Полезно помнить, что современные браузеры предпринимают шаги по ограничение уровня эксплуатации проблем вроде непостоянных XSS и основанных на DOM XSS. В том числе это нужно помнить при тестировании веб-сайтов с помощью браузера – вполне может оказаться, что веб-приложение уязвимо, но вы не видите всплывающего подтверждения только по той причине, что его блокирует браузер.
Примеры эксплуатирования XSS
Злоумышленники, намеревающиеся использовать уязвимости межсайтового скриптинга, должны подходить к каждому классу уязвимостей по-разному. Здесь описаны векторы атак для каждого класса.
При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.
Пример атаки с непостоянным XSS
1. Алиса часто посещает определённый веб-сайт, который хостит Боб. Веб-сайт Боба позволяет Алисе осуществлять вход с именем пользователя/паролем и сохранять чувствительные данные, такие как платёжная информация. Когда пользователь осуществляет вход, браузер сохраняет куки авторизации, которые выглядят как бессмысленные символы, т.е. оба компьютера (клиент и сервер) помнят, что она вошла.
2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:
2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид поисковый запрос
2.2 С нормальным поисковым запросом вроде слова «собачки» страница просто отображает «собачки не найдено» и url собачки, что является вполне нормальным поведением.
2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде <script type='text/javascript'>alert('xss');</script>:
2.3.1 Появляется сообщение с предупреждением (которое говорит "xss").
2.3.2 Страница отображает <script type='text/javascript'>alert('xss');</script> не найдено наряду с сообщением об ошибке с текстом 'xss'.
2.3.3 url, пригодный для эксплуатации <script%20type='text/javascript'>alert('xss');</script>
3. Мэлори конструирует URL для эксплуатации уязвимости:
3.1 Она делает URL <script%20src=""></script>. Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.
3.2 Она отправляет e-mail некоторым ничего не подозревающим членом сайта Боба, говоря: «Зацените клёвых собачек».
4. Алиса получает письмо. Она любит собачек и кликает по ссылке. Она переходит на сайт Боба в поиск, она не находит ничего, там отображается «собачки не найдено», а в самой середине запускается тэг со скриптом (он невидим на экране), загружает и выполняет программу Мэлори authstealer.js (срабатывание XSS атаки). Алиса забывает об этом.
5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.
6. Мэлори теперь размещает куки авторизации Алисы в своём браузере как будто бы это её собственные. Затем она переходит на сайт Боба и оказывается залогиненной как Алиса.
7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.
8. Она решает сделать следующий шаг и отправляет сконструированную подобным образом ссылку самому Бобу, и таким образом получает административные привилегии сайта Боба.
Атака с постоянным XSS
Поиск сайтов уязвимых к XSS
Дорки для XSS
Первым шагом является выбор сайтов, на которых мы будем выполнять XSS атаки. Сайты можно искать с помощью дорков Google. Вот несколько из таких дорков, которые скопируйте и вставьте в поиск Гугла:
Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения – WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже.
Самые лучшие цели – это разнообразные самописные движки и скрипты.
В качестве полезной нагрузки для вставки можно выбрать
<script>alert(1)</script>
Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода (input ):
<input type="text" class="ui-input query" name="q" value="наволочка"/><script>alert(1)</script><input value="" />
Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input. Мы можем этого избежать – закроем двойную кавычку, а затем и сам тэг с помощью "/>
В результате полезная нагрузка приобретает вид:
"/><sсript>alert(1)</script>
Давайте попробуем её для какого-нибудь сайта:
Отлично, уязвимость имеется
Программы для поиска и сканирования XSS уязвимости
Наверное, все сканеры веб-приложений имеют встроенный сканер XSS уязвимостей. Эта тема неохватная, лучше знакомиться с каждым подобным сканером отдельно.
Имеются также специализированные инструменты для сканирования на XSS уязвимости. Среди них особенно можно выделить:
Уязвимые веб-приложения для тестирования XSS
Большинство наборов уязвимых веб-приложений (кроме некоторых узкоспециальных) имеют в своём составе сайты, уязвимые к XSS. Самым лучшим вариантом является их использование в автономной среде обучения , который собрал множество приложений для тестирования. Например, свои навыки по выявлению и эксплуатации XSS можно тренировать на:
Damn Vulnerable Web App (DVWA):
Mutillidae/NOWASP (очень много самых разнообразных вариаций XSS)
WebGoat (аналогично, очень много всего связанного с XSS)
Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении кода, исполняемого на стороне клиента (JavaScript) в веб-страницу, которую просматривают другие пользователи.
Уязвимость возникает из-за недостаточной фильтрации данных, которые пользователь отправляет для вставки в веб-страницу. Намного проще понять на конкретном пример. Вспомните любую гостевую книгу – это программы, которые предназначены для принятия данных от пользователя и последующего их отображения. Представим себе, что гостевая книга никак не проверяет и не фильтрует вводимые данные, а просто их отображает.
Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP – этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке:
Если кто-то из пользователей ввёл:
Привет! Нравится твой сайт.
То веб-страница отобразит:
Привет! Нравится твой сайт.
А если пользователь введёт так:
Привет! Нравится твой сайт.<script>alert("Pwned")</script>
То отобразиться это так:
Браузеры хранят множества кукиз большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.
Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.
Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта.
Внедрённый код умеет всё то, что умеет JavaScript, а именно:
- получает доступ к кукиз просматриваемого сайта
- может вносить любые изменения во внешний вид страницы
- получает доступ к буферу обмена
- может внедрять программы на JavaScript, например, ки-логеры (перехватчики нажатых клавиш)
- подцеплять на BeEF
- и др.
<script>alert(document.cookie)</script>
На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.
Виды XSS
Самое главное, что нужно понимать про виды XSS то, что они бывают:
- Хранимые (Постоянные)
- Отражённые (Непостоянные)
- Введённое злоумышленником специально сформированное сообщение в гостевую книгу (комментарий, сообщение форума, профиль) которое сохраняется на сервере, загружается с сервера каждый раз, когда пользователи запрашивают отображение этой страницы.
- Злоумышленник получил доступ к данным сервера, например, через SQL инъекцию, и внедрил в выдаваемые пользователю данные злонамеренный JavaScript код (с ки-логерами или с BeEF).
- На сайте присутствует поиск, который вместе с результатами поиска показывает что-то вроде «Вы искали: [строка поиска]», при этом данные не фильтруются должным образом. Поскольку такая страница отображается только для того, у кого есть ссылка на неё, то пока злоумышленник не отправит ссылку другим пользователям сайта, атака не сработает. Вместо отправки ссылки жертве, можно использовать размещение злонамеренного скрипта на нейтральном сайте, который посещает жертва.
- DOM-модели
Особенности XSS основанных на DOM
Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:
"/><script>alert(1)</script>
А при открытии исходного HTML кода мы видим что-то вроде такого:
<div class="m__search">
<form method="get" action="/search.php">
<input type="text" class="ui-input query" name="q" value=""/><script>alert(1)</script>" /> <button type="submit" class="ui-button">Найти</button>
</form>
А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:
<!DOCTYPE html>
<html>
<head>
<title>HackWare.ru::
OM XSS</title><meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div id="default"> An error occurred...</div>
<script>
function OnLoad() {
var foundFrag = get_fragment();
return foundFrag;
}
function get_fragment() {
var r4c = '(.*?)';
var results = location.hash.match('.*input=token(' + r4c + ');');
if (results) {
document.getElementById("default").innerHTML = "";
return (unescape(results[2]));
} else {
return null;
}
}
display_session = OnLoad();
document.write("Your session ID was: " + display_session + "<br><br>")
</script>
</body>
</html>
Если мы перейдём по примерно такой ссылке
То в браузере мы увидим:
Исходный код страницы:
Давайте сформируем адрес следующим образом:
<script>alert(1)</script>;
Теперь страница выглядит так:
Но давайте заглянем в исходный код HTML:
Там совершенно ничего не изменилось. Про это я и говорил, нам нужно смотреть DOM структуру документа, чтобы выявить злонамеренный код:
Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:
<script>alert(1)%3balert(2)</script>;
Где мы заменили символ ; на кодированный в URI эквивалент!
Теперь мы можем написать вредоносную полезную нагрузку JavaScript и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга.
XSS Auditor
В Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз:
dom_xss.html:30 The XSS Auditor refused to execute a script in '<script>alert(1)</script>;' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.
Т.е. теперь в браузере есть XSS аудитор, который будет пытаться предотвращать XSS. В Firefox ещё нет такой функциональности, но, думаю, это дело времени. Если реализация в браузерах будет удачной, то можно говорить о значительном затруднении применения XSS.
Полезно помнить, что современные браузеры предпринимают шаги по ограничение уровня эксплуатации проблем вроде непостоянных XSS и основанных на DOM XSS. В том числе это нужно помнить при тестировании веб-сайтов с помощью браузера – вполне может оказаться, что веб-приложение уязвимо, но вы не видите всплывающего подтверждения только по той причине, что его блокирует браузер.
Примеры эксплуатирования XSS
Злоумышленники, намеревающиеся использовать уязвимости межсайтового скриптинга, должны подходить к каждому классу уязвимостей по-разному. Здесь описаны векторы атак для каждого класса.
При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.
Пример атаки с непостоянным XSS
1. Алиса часто посещает определённый веб-сайт, который хостит Боб. Веб-сайт Боба позволяет Алисе осуществлять вход с именем пользователя/паролем и сохранять чувствительные данные, такие как платёжная информация. Когда пользователь осуществляет вход, браузер сохраняет куки авторизации, которые выглядят как бессмысленные символы, т.е. оба компьютера (клиент и сервер) помнят, что она вошла.
2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:
2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид поисковый запрос
2.2 С нормальным поисковым запросом вроде слова «собачки» страница просто отображает «собачки не найдено» и url собачки, что является вполне нормальным поведением.
2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде <script type='text/javascript'>alert('xss');</script>:
2.3.1 Появляется сообщение с предупреждением (которое говорит "xss").
2.3.2 Страница отображает <script type='text/javascript'>alert('xss');</script> не найдено наряду с сообщением об ошибке с текстом 'xss'.
2.3.3 url, пригодный для эксплуатации <script%20type='text/javascript'>alert('xss');</script>
3. Мэлори конструирует URL для эксплуатации уязвимости:
3.1 Она делает URL <script%20src=""></script>. Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.
3.2 Она отправляет e-mail некоторым ничего не подозревающим членом сайта Боба, говоря: «Зацените клёвых собачек».
4. Алиса получает письмо. Она любит собачек и кликает по ссылке. Она переходит на сайт Боба в поиск, она не находит ничего, там отображается «собачки не найдено», а в самой середине запускается тэг со скриптом (он невидим на экране), загружает и выполняет программу Мэлори authstealer.js (срабатывание XSS атаки). Алиса забывает об этом.
5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.
6. Мэлори теперь размещает куки авторизации Алисы в своём браузере как будто бы это её собственные. Затем она переходит на сайт Боба и оказывается залогиненной как Алиса.
7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.
8. Она решает сделать следующий шаг и отправляет сконструированную подобным образом ссылку самому Бобу, и таким образом получает административные привилегии сайта Боба.
Атака с постоянным XSS
- Мэлори имеет аккаунт на сайте Боба.
- Мэлори замечает, что веб-сайт боба содержит постоянную XSS уязвимость. Если вы переходите в новый раздел, размещаете комментарий, то он отображает что бы в него не напечатали. Но если текст комментария содержит HTML тэги, эти тэги будут отображены как есть, и любые тэги скриптов запускаются.
- Мэлори читает статью в разделе Новости и пишет комментарий в разделе Комментарии. В комментарий она вставляет текст:
- В этой истории мне так понравились собачки. Они такие славные! <script src="">
- Когда Алиса (или ещё кто-либо) загружают страницу с этим комментарием, тэг скрипта Мэлори запускается и ворует куки авторизации Алисы, отправляет на секретный сервер Мэлори для сбора.
- Мэлори теперь может перехватить сессию Алисы и выдать себя за Алису.
Поиск сайтов уязвимых к XSS
Дорки для XSS
Первым шагом является выбор сайтов, на которых мы будем выполнять XSS атаки. Сайты можно искать с помощью дорков Google. Вот несколько из таких дорков, которые скопируйте и вставьте в поиск Гугла:
- inurl:search.php?q=
- inurl:.php?q=
- inurl:search.php
- inurl:.php?search=
Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения – WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже.
Самые лучшие цели – это разнообразные самописные движки и скрипты.
В качестве полезной нагрузки для вставки можно выбрать
<script>alert(1)</script>
Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода (input ):
<input type="text" class="ui-input query" name="q" value="наволочка"/><script>alert(1)</script><input value="" />
Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input. Мы можем этого избежать – закроем двойную кавычку, а затем и сам тэг с помощью "/>
В результате полезная нагрузка приобретает вид:
"/><sсript>alert(1)</script>
Давайте попробуем её для какого-нибудь сайта:
Отлично, уязвимость имеется
Программы для поиска и сканирования XSS уязвимости
Наверное, все сканеры веб-приложений имеют встроенный сканер XSS уязвимостей. Эта тема неохватная, лучше знакомиться с каждым подобным сканером отдельно.
Имеются также специализированные инструменты для сканирования на XSS уязвимости. Среди них особенно можно выделить:
- XSSer – это не только мощный сканер, который умеет использовать разные методы внедрения и обхода фильтрации, это также автоматизированный инструмент по поиску уязвимых к XSS сайтов (по доркам). Для сайтов с найденными уязвимостями умеет внедрять полезную нагрузку для реальной атаки;
- XssPy – тоже достаточно самостоятельный инструмент, который умеет находить все страницы сайта (в том числе и на субдоменах) и проверять все элементы ввода на этих страницах;
- BruteXSS – положительной особенностью этого инструмента является полное исключение ложных срабатываний.
Уязвимые веб-приложения для тестирования XSS
Большинство наборов уязвимых веб-приложений (кроме некоторых узкоспециальных) имеют в своём составе сайты, уязвимые к XSS. Самым лучшим вариантом является их использование в автономной среде обучения , который собрал множество приложений для тестирования. Например, свои навыки по выявлению и эксплуатации XSS можно тренировать на:
Damn Vulnerable Web App (DVWA):
- (непостоянная XSS)
- (хранимая XSS)
Mutillidae/NOWASP (очень много самых разнообразных вариаций XSS)
WebGoat (аналогично, очень много всего связанного с XSS)
