Тестирование межсайтового скриптинга

Межсайтовый скриптинг (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-адрес, в который помещаются данные.

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