XSS: Stored XSS — Сохранённые межсайтовые сценарии

Что такое сохранённые межсайтовые сценарии

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

Предположим, веб-сайт позволяет пользователям оставлять комментарии к сообщениям в блогах отображаемые другим пользователям. Пользователи отправляют комментарии с помощью HTTP-запроса, например:

POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100

postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net

После отправки этого комментария любой пользователь, посетивший сообщение в блоге, получит следующий ответ приложения:

<p>This post was extremely helpful.</p>

Предполагая, что приложение не выполняет никакой другой обработки данных, злоумышленник может отправить вредоносный комментарий, подобный этому:

<script>/* Bad stuff here... */</script>

В запросе злоумышленника этот комментарий будет закодирован в URL как:

comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

Любой пользователь, посетивший сообщение в блоге, теперь получит в ответе приложения следующее:

<p><script>/* Bad stuff here... */</script></p>

Сценарий предоставленный злоумышленником будет выполняться в браузере пользователя-жертвы в контексте его сеанса с приложением.

Влияние сохранённых XSS атак

Если злоумышленник может управлять сценарием выполняющимся в браузере жертвы, как правило, он может полностью скомпрометировать этого пользователя. Злоумышленник может выполнять любые действия, применимые к воздействию Отражённых XSS уязвимостей.

С точки зрения возможности использования, ключевое различие между Отражённой XSS и Сохранённой XSS заключается в том, что Сохранённая XSS уязвимость делает возможным атаки остающиеся автономными внутри самого приложения. Злоумышленнику не нужно искать внешний способ побудить других пользователей сделать конкретный запрос, содержащий эксплойт. Скорее, злоумышленник помещает свой эксплойт в само приложение и просто ждёт, пока пользователи не столкнутся с ним.

Автономный характер хранимых эксплойтов межсайтовых сценариев особенно актуален, когда XSS уязвимость влияет только на пользователей, которые в данный момент вошли в приложение. Если это Отражённый XSS, то атака должна быть рассчитана на везение: пользователь, который вынужден сделать запрос злоумышленника в то время, когда он не вошёл в систему, не будет скомпрометирован. Напротив, если это Сохранённая XSS, то пользователь гарантированно войдёт в систему в момент когда столкнётся с эксплойтом.

Сохранённые XSS в разных контекстах

Существует множество разновидностей хранимых межсайтовых сценариев. Расположение сохранённых данных в ответе приложения определяет, какой тип полезной нагрузки требуется для его использования, а также может повлиять на уязвимость.

Кроме того, если приложение выполняет какую-либо проверку или другую обработку данных перед их сохранением или в момент, когда сохранённые данные включаются в ответы, это обычно влияет на то, какой тип XSS полезной нагрузки необходим.

Как найти и протестировать Сохранённые XSS уязвимости

Многие Сохранённые XSS уязвимости можно найти с помощью сканера уязвимостей.

Тестирование Сохранённых XSS уязвимостей вручную может быть сложной задачей. Вам необходимо протестировать все соответствующие точки входа, через которые данные, контролируемые злоумышленником, могут попасть в обработку приложения и все точки выхода, в которых эти данные могут появиться в ответах приложения.

Точки входа приложения включают:

• Параметры или другие данные в строке запроса URL и в тексте сообщения.
• URL-путь.
• Заголовки HTTP-запросов, которые могут быть неприменимы в отношении Отражённого XSS.
• Любые внеполосные маршруты, по которым злоумышленник может доставлять данные в приложение. Существующие маршруты полностью зависят от функциональности реализуемой приложением: приложение веб-почты будет обрабатывать данные, полученные в электронных письмах; приложение, отображающее ленту Twitter, может обрабатывать данные, содержащиеся в сторонних твитах; а агрегатор новостей будет включать данные с других веб-сайтов.

Точки выхода для Сохранённых XSS атак — все возможные HTTP-ответы, возвращаемые любому пользователю приложения в любой ситуации.

Первый шаг в тестировании Сохранённых XSS уязвимостей — обнаружение связей между точками входа и выхода, посредством которых данные отправленные в точку выхода отправляются из точки входа. Причины, которые могут вызвать сложности заключаются в следующем:

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

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

Вместо этого более реалистичным подходом является систематическая работа с точками ввода данных, отправка определённого значения в каждую из них и отслеживание ответов приложения для обнаружения случаев появления представленного значения. Особое внимание можно уделить соответствующим функциям приложения, таким как комментарии к сообщениям в блогах. Когда отправленное значение наблюдается в ответе, вам необходимо определить, действительно ли данные хранятся в разных запросах, а не просто отображаются в немедленном ответе.

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