Тестирование межсайтового скриптинга
Межсайтовый скриптинг (XSS) происходит всякий раз, когда приложение берет ненадежные данные и отправляет их клиенту (браузеру) без проверки. Это позволяет злоумышленникам выполнять вредоносные сценарии в браузере жертвы, что может привести к захвату сеансов пользователя, повреждению веб-сайтов или перенаправлению пользователя на вредоносные сайты.
Давайте разберемся с агентами угроз, векторами атак, слабостями безопасности, техническим воздействием и последствиями для бизнеса этой уязвимости с помощью простой диаграммы.
Типы XSS
Stored XSS - Сохраненный XSS, также известный как постоянный XSS, возникает, когда вводимые пользователем данные хранятся на целевом сервере, например, в базе данных / форуме сообщений / поле комментариев и т. Д. Затем жертва может получить сохраненные данные из веб-приложения.
Reflected XSS - Отраженный XSS, также известный как непостоянный XSS, возникает, когда вводимые пользователем данные немедленно возвращаются веб-приложением в сообщении об ошибке / результате поиска или вводятся пользователем как часть запроса и без постоянного хранения данных, предоставленных пользователем.
DOM Based XSS - XSS на основе DOM - это форма XSS, когда источник данных находится в DOM, приемник также находится в DOM, а поток данных никогда не покидает браузер.
пример
Приложение использует ненадежные данные при построении без проверки. Специальные символы должны быть экранированы.
http://www.webpage.org/task/Rule1?query=tryЗлоумышленник изменяет параметр запроса в своем браузере на -
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>Руки вверх
Step 1- Войдите в Webgoat и перейдите в раздел межсайтового скриптинга (XSS). Давайте выполним атаку с использованием хранимых межсайтовых сценариев (XSS). Ниже приведен снимок сценария.
Step 2- В соответствии со сценарием, давайте войдем как Том с паролем «Том», как указано в самом сценарии. Нажмите «просмотреть профиль» и войдите в режим редактирования. Поскольку злоумышленник является томом, давайте внедрим сценарий Java в эти поля редактирования.
<script>
alert("HACKED")
</script>
Step 3 - Как только обновление закончится, Том получит окно предупреждения с сообщением «взломано», что означает, что приложение уязвимо.
Step 4 - Теперь, согласно сценарию, нам нужно войти в систему как jerry (HR) и проверить, не влияет ли внедренный скрипт на jerry.
Step 5 - После входа в систему как Джерри выберите «Том» и нажмите «просмотреть профиль», как показано ниже.
При просмотре профиля Тома из учетной записи Джерри он может получить такое же окно сообщения.
Step 6 - Это окно сообщения является всего лишь примером, но фактический злоумышленник может выполнять гораздо больше, чем просто отображать окно сообщения.
Профилактические механизмы
Разработчики должны убедиться, что они избегают всех ненадежных данных на основе контекста HTML, такого как тело, атрибут, JavaScript, CSS или URL-адрес, в который помещаются данные.
Для тех приложений, которым требуются специальные символы в качестве входных данных, должны существовать надежные механизмы проверки, прежде чем они будут приняты как допустимые входные данные.