Сегодня разберем еще парочку простеньких XSS.

1.) Lab: Stored XSS into HTML context with nothing encoded

Название и краткое описание данной работы наталкивают на мысль, что XSS должна быть хранимой (т.е. payload должен быть загружен на серверную часть приложения). Посмотрим, какой функционал может быть язвим к Stored XSS

Попробуем вписать в поле самого комментария самый банальный payload:

<script>alert('Stored XSS detected!')</script>

Оставшиеся поля заполним простой информацией и посмотрим на реакцию приложения.

Lab: DOM XSS in document.write sink using source location.search

Начнем с короткого теоретического ликбеза. Данный тип XSS выполняется на клиентской стороне приложения - не отражается и не хранится на сервере. При возникновении данной уязвимости приложение отображает вредоносный код как часть DOM.

DOM (document objetc model) - объектная модель, которую браузер создает на основе полученного HTML. Важно отметить, что в DOM-XSS не изменяется исходный HTML, изменяется именно DOM. Идем решать лабу!

В описании к лабе нас просять вызвать функцию alert и сильно намекают на document.write и location.search. Посмотрим, какой функционал сайта мы будем истязать для получения DOM-XSS...

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

Наш поисковый запрос выполняется с помощью document.write. Непосредственно наш запрос располагается после searchTerms. Запихнуть банальный payload прямо в поисковое поле уже не выйдет, а жаль... Однако заметим, что мы также можем изменять URL, т.к. в нем отображается наш поисковый запрос. Что же, попробуем составить правильный payload и вписать его в URL.

"><svg onload=alert(1)>

Почему же payload именно такой??? Вообще составление правильного payload для XSS это уже почти гарантированный успех. Итак, объяснение!

"> - закрывает параметр и тег input, а остальное тело payload является базовым payload для svg. Почему svg? Данный payload мы можем использовать внутри тега img. Что же попробуем выполнить данный payload.

Вывод

Что? Куда? Ответы на эти вопросы полностью решают задачу успешной эксплуатации XSS. Составление правильного payload - сравни искусству! Упражняйтесь и ищите информацию в интернете:)

P.s. Хранимый XSS - самый опасный вид XSS, т.к. злоумышленнику достаточно отправить payload на сервер веб-приложения один раз, а жертва будет уязвима всякий раз, когда будет выполнять действия достаточные для выполнения полезной нагрузки (как в первом примере этой статьи)