Учебники

Тестирование межсайтовых сценариев

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

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

3. межсайтовый скриптинг

Типы XSS

  • Сохраненный XSS — сохраненный XSS, также известный как постоянный XSS, возникает, когда пользовательский ввод хранится на целевом сервере, таком как база данных / форум сообщений / поле комментариев и т. Д. Затем жертва может извлечь сохраненные данные из веб-приложения.

  • Отраженный XSS — отраженный XSS, также известный как непостоянный XSS, возникает, когда пользовательский ввод немедленно возвращается веб-приложением в сообщении об ошибке / результате поиска или вводом, предоставленным пользователем как часть запроса, и без постоянного сохранения данных, предоставленных пользователем. ,

  • Основанный на DOM XSS — Основанный на DOM XSS является формой XSS, когда источник данных находится в DOM, приемник также находится в DOM, и поток данных никогда не покидает браузер.

Сохраненный XSS — сохраненный XSS, также известный как постоянный XSS, возникает, когда пользовательский ввод хранится на целевом сервере, таком как база данных / форум сообщений / поле комментариев и т. Д. Затем жертва может извлечь сохраненные данные из веб-приложения.

Отраженный XSS — отраженный XSS, также известный как непостоянный XSS, возникает, когда пользовательский ввод немедленно возвращается веб-приложением в сообщении об ошибке / результате поиска или вводом, предоставленным пользователем как часть запроса, и без постоянного сохранения данных, предоставленных пользователем. ,

Основанный на DOM XSS — Основанный на DOM XSS является формой XSS, когда источник данных находится в DOM, приемник также находится в DOM, и поток данных никогда не покидает браузер.

пример

Приложение использует ненадежные данные в конструкции без проверки. Специальные символы должны быть экранированы.

http://www.webpage.org/task/Rule1?query=try

Злоумышленник изменяет параметр запроса в своем браузере на —

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Руки вверх

Шаг 1 — Войдите в Webgoat и перейдите в раздел межсайтовых скриптов (XSS). Давайте выполним атаку по сохраненным межсайтовым сценариям (XSS). Ниже приведен снимок сценария.

3. xss

Шаг 2 — В соответствии со сценарием, давайте войдем в систему как Tom с паролем ‘Tom’, как указано в самом сценарии. Нажмите «Просмотр профиля» и войдите в режим редактирования. Поскольку Том является злоумышленником, давайте вставим Java-скрипт в эти поля редактирования.

<script> 
   alert("HACKED")
</script> 

3. xss

Шаг 3 — Как только обновление закончится, Том получает окно с сообщением «взломан», что означает, что приложение уязвимо.

3. xss

Шаг 4. Теперь в соответствии со сценарием нам нужно войти в систему как jerry (HR) и проверить, не влияет ли на jerry внедренный скрипт.

3. xss

Шаг 5 — После входа в систему как Джерри, выберите «Том» и нажмите «Просмотр профиля», как показано ниже.

3. xss

При просмотре профиля Тома из учетной записи Джерри, он может получить то же сообщение.

3. xss

Шаг 6 — Это окно сообщения является только примером, но фактический злоумышленник может выполнить гораздо больше, чем просто отобразить окно сообщения.

Разработчики должны убедиться, что они избегают всех ненадежных данных на основе контекста HTML, такого как тело, атрибут, JavaScript, CSS или URL-адрес, в который помещаются данные.

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