Stored XSS с помощью html injection на примере онлайн-библиотеки

na_official · 3 апр 2023

Дисклеймер: в данной статье описывается технический пример реализации Stored XSS на примере старого сайта. На более современных сайтах такой тупой способ не сработает, но паттерн тот же. Тем не менее, весь материал здесь написан только в теоретических целях и я не несу ответственность за ваши действия.
Привет, пользователь lolz !
В этой теме - простой пример HTML-инъекции на реальном сайте онлайн-библиотеки и обход простейшего WAF для эксплуатации Stored XSS.

Для начала, что такое Stored XSS?
XSS (межсайтовый скриптинг) - это уязвимость, которая позволяет выполнять произвольный вредоносный JS-код на стороне клиента. Обычно выделяют 2 типа XSS
1. Stored (хранимые) XSS - самые серьезные XSS-ки, поскольку вредоносный код внедряется напрямую в страницу, которая может быть найдена в поиске или переходом по внутренней ссылке.
2. Reflected XSS - чуть менее опасные, но менее серьезные уязвимости, которые отрисовывают DOM в браузере, используя значения из передаваемых в URL параметрах. Чтобы сработала такая уязвимость, жертве необходимо перейти по специально сформированной ссылке.

Вот пример Reflected XSS. Например, запрос к Google имеет такой вид:
https://google.com/search?q=lolz

Код
https://google.com/search?q=lolz
Как видно, параметр q передается в поле поиска. Если бы в Google существовала уязвимость Reflected XSS, то при переходе по ссылке

https://google.com/search?q=<script>alert(1)</script>

Код

https://google.com/search?q=<script>alert(1)</script>

Этот код был бы выполнен и пользователь получил всплывающее окно.

Сегодня мы говорим о Stored XSS. Для простоты покажу на этом же примере с гуглом.
В поиске у нас отображаются сайты с кратким описанием, которое берется из мета-тегов на главной странице.
То есть создатели сайта указывают информацию, которую Google отображает в описании карточки сайта в поисковой выдаче.

Такая XSS-ка была бы Stored, поскольку данные о сайте для поисковой выдаче Google хранит на своей стороне и эти данные не зависят от параметров URL-адреса.

Где чаще всего можно встретить Stored XSS? Ответ - на сайтах, где требуется вводить какие-то данные, которые сохраняются и отображаются пользователям. Например, это социальные сети, сервисы для отзывов, комментариев и т.д.

Перейдем к нашему примеру. Наш сайт - http://www.cnshb.ru/AKDiL/0031/Base/RT/001026.shtm (не реклама, есть гораздо больше сайтов с актуальной и полной информацией и нормальным дизайном). На этой конкретной странице онлайн-библиотеки мы видим кнопку "Ваши замечания". Нажимаем и попадаем в меню с комментариями пользователей.

Самое первое, что должно придти в голову при виде такого поля - получить HTMLi - инъекцию HTML-кода.
Оставим комментарий с текстом

<span style="color:red">Lolz ку!</span>

HTML

<span style="color:red">Lolz ку!</span>

Как видим, наша простейшая HTMLi сработала - текст стал красным!
Попробуем добавить простейший скрипт с всплывающим окном:

<script>alert(1)</script>

HTML

<script>alert(1)</script>

Не сработало. Смотрим в Devtools, почему:

Видим, что наши скобки были заменены на квадратные ([]). Это означает, что на сайте есть какой-то простейший WAF, который пытается блокировать XSS.
Попробуем обойти защиту, заменив скобки на кавычки (``):

<script>alert`1`</script>

HTML

<script>alert`1`</script>

Успех! Теперь при заходе в раздел комментариев на этой странице любой пользователь исполнит наш встроенный код.

На данном сайте сильнее раскрутить эту уязвимость вряд-ли получится, но хочу поделиться импактом подобной найденной Stored XSS-уязвимости во ВКонтакте . Там я вытягивал короткодействующий access_token (ключ доступа, с которым можно делать почти все с аккаунтом его владельца) из localStorage (хранилище данных в браузере, доступ к которому можно получить с помощью JS) и выполнял fetch-запросы к API от имени атакованного пользователя. В качестве безобидного proof of concept я сделал ссылку, по переходу по которой от имени пользователя отправлялось сообщение себе же в личку о том, что его взломали.

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

Надеюсь, после прочтения этой статьи вы разобрались в теме XSS-уязвимостей и научились их искать, используя базовые инструменты (вроде Devtools). Спасибо.