Содержание

Что такое XSS-уязвимость и как тестировщику не пропустить ее / Хабр

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

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



Определение

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен. А дальше существует несколько сценариев развития.

Первый: злоумышленнику удастся заполучить авторизационные данные пользователя и войти в его аккаунт.

Второй: злоумышленник может незаметно для жертвы перенаправить его на другую страницу-клон. Эта страница может выглядеть совершенно идентично той, на которой пользователь рассчитывал оказаться. Но вот принадлежать она будет злоумышленнику. Если пользователь не заметит подмены и на этой странице введет какие-то sensitive data, то есть личные данные, они окажутся у злоумышленника.

Третий… да в общем-то много чего еще можно придумать. Почти все, что может JavaScript, становится доступным для злоумышленника. Чуть ниже мы рассмотрим подробнее один из таких примеров. А пока давайте попробуем чуть подробнее обсудить, как именно устроена уязвимость. И почему злоумышленнику удается внедрить свой код в чужое приложение без доступа к его исходникам.

Небольшое предупреждение. Вся информация далее представлена исключительно в информационных целях. Тестировщик должен уметь проверять свое веб-приложение на уязвимости. Однако, использование XSS-уязвимостей на чужих ресурсах является незаконным.

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

Но вернемся к XSS.

Как устроена уязвимость?

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

Например, можно добавить JavaScript-код в поле ввода, текст из которого сохраняется и в дальнейшем отображается на странице для всех пользователей.

Это может быть поле для ввода информации о себе на странице профиля социальной сети или комментарии на форуме.

Злоумышленник вводит текст (и за одно вредоносный код), который сохраняется на странице. Когда другие пользователи зайдут на эту же страницу, вместе с текстом они загрузят и JavaScript-код злоумышленника. Именно в момент загрузки этот код отработает. Конечно, уязвимость сработает, только если текст при сохранении не будет обезопасен. О том, как это сделать, и почему разработчики иногда забывают об этом, поговорим чуть позже.

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

А пока давайте двигаться дальше.

Почему такие ошибки часто встречаются на веб-проектах?

Суть в том, что браузер не может самостоятельно отличить обычный текст от текста, который является CSS, HTML или JavaScript-кодом. Он будет пытаться обрабатывать все, что находится между тегами <script>, как JavaScript-код. Все, что находится между тегами <style>, считать CSS. И все, что похоже на тег, считать HTML-кодом.

Если разработчик хочет, чтобы какой-то текст только выглядел как код, но таковым не являлся (то есть не обрабатывался браузером, а выводился как есть), этот текст надо специально обработать прежде, чем отдать его браузеру. Такая обработка называется “экранированием”.

В процессе экранирования текста в этом тексте все спец. символы заменяются их “аналогами”, и браузер уже знает наверняка, что это просто текст. Важнее всего обрабатывать тот текст, который приходит от пользователя, так как любой пользователь может оказаться злоумышленником и вместе с текстом прислать какой-нибудь код. Увы, иногда разработчики забывают об экранировании в тех или иных местах веб-приложения, и текст выводится без всякой обработки. Причин для этого может быть несколько.

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

Более того, иногда разные части сайта могут создаваться в разное время и/или разными людьми. В этом случае вероятность ошибки возрастает.

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

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

В этом случае вся надежда на тестировщиков.

Чем опасна XSS-уязвимость?

Давайте еще раз, более детально, поговорим об опасности XSS-уязвимости. Сама по себе уязвимость не является опасной. Опасной она становится тогда, когда ее находит злоумышленник и начинает ее использовать в своих целях. Использование уязвимости называется “вектором атаки”. В случае XSS векторов атаки довольно много.

Самый простой пример — кража авторизационных cookie пользователей веб-приложения. Чаще всего сайт, на котором присутствует авторизация, отличает авторизованного пользователя по так называемой сессионной cookie. Если ее нет, то пользователь не авторизован. А если она есть, то по значению этой cookie сервер может отличить одного пользователя от другого.

Все cookie хранятся на компьютере пользователей. Если я авторизуюсь своим пользователем, я буду видеть свое значение cookie. А значение чужой просто так узнать не смогу.

То же касается JavaScript-кода, который выполняется в браузере пользователя. Этот JavaScript-код будет видеть значение cookie того пользователя, в браузере которого он исполняется и только его.

Теперь допустим, что злоумышленнику удастся внедрить JavaScript-код на страницу веб-приложения. У любого пользователя, который теперь зайдет на эту страницу, будет исполняться в браузере JavaScript-код. Он будет читать значение cookie этого пользователя (теперь уже жертвы). Осталось только передать это значение злоумышленнику — и дело сделано. Но как передать значение, ведь вредоносный код исполняется в браузере жертвы?

Все довольно просто. Этот же JavaScript-код может создать AJAX-запрос на удаленный сервер. Например, на вот такой URL: www.zloy-site.ru/stolen={значение_cookie_жертвы}

Домен zloy-site принадлежит злоумышленнику из нашего примера. Все запросы, которые приходят на этот домен, записываются в базу данных. Посмотрев на параметры URL, злоумышленник узнает значения cookie жертв и сможет их использовать, чтобы попасть в их аккаунты.

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

Где искать XSS? Как с ней бороться? Демо-страница с примером

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

Если он может добавить в какое-то место определенный текст, он сможет попытаться добавить и JavaScript-код.

Давайте это рассмотрим на конкретном примере. Я подготовил очень простую песочницу, где спряталась XSS-уязвимость. Предлагаю попробовать ее найти вместе.

Открываем песочницу: https://playground.learnqa.ru/demo/xss

Для начала посмотрим, как устроена страница. Это по сути очень простой каталог книг, в котором есть поиск. Если ввести в запросе “Рей Брэдбери” мы увидим все книги, которые есть в этом каталоге этого автора.

Внимательный пользователь уже заметил, что текст, который мы вводили в поле поиска, тут же оказался в URL. Нам этот момент еще пригодится.

А пока давайте попробуем вставить какую-нибудь ерунду в поле поиска: “fwefewf”.

Мы увидим, что в этом случае ничего найти на странице не удалось. А текст запроса повторился в тексте ошибки:

Итак, мы с вами обнаружили место, где появляется текст, вводимый нами. Следовательно, это и есть потенциальное место для XSS-уязвимости. Давайте попробуем вставить самый популярный JavaScript-код для проверки, есть ли там уязвимость.

<script>alert(123)</script>

В случае, если страница является уязвимой, после ввода этого кода на странице появится вот такое окошко:

Оно и будет означать, что наш JavaScript-код исполнился и мы нашли XSS-уязвимость.

Итак, вводим код и видим следующее предупреждение:

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

Помните, чуть выше мы с вами заметили, что текст, который мы вводим в поле поиска, отображается в URL в так называемом GET-параметре? Имя этого параметра “q”, а значение — то, что мы вводим в поле поиска. Это сделано для того, чтобы можно было скопировать URL вместе с этой самой строкой поиска и в следующий раз открыть страницу сразу с нужными авторами.

Например, вот такой URL откроет страницу сразу только с книгами Рея Брэдбери: playground.learnqa.ru/demo/xss?q=Рей+Брэдбери

В отличие от формы, валидацию URL разработчик сделать не мог — любой пользователь в своем браузере может ввести любой URL, какой захочет, в том числе и с любым значением GET-параметра. Задача разработчика в этом случае — не забыть учесть все варианты и написать правильный обработчик значения этого GET-параметра.

Проверим, не забыл ли наш разработчик все учесть тут. Попробуем в GET-параметр “q” подставить тот самый JavaScript-код: https://playground.learnqa.ru/demo/xss?q=<script>alert(123)</script>

Перейдя по этому URL мы видим, что на странице появилось окошко со значением 123. Но почему?

Все довольно просто. Помните, когда сайт не может найти нужные книги по заданному поисковому запросу, он текст этого поискового запроса выводит в тексте ошибке? Мол, не нашли ничего по запросу “бла-бла”. Вот вместо этого “бла-бла” у нас теперь JavaScript-код с алертом. Разработчик написал валидацию поля ввода и решил, что так он защитил сайт от того, чтобы JavaScript мог оказаться в поисковом запросе. И не стал экранировать текст ошибки. Нам же удалось обойти валидацию через URL, поменяв там значение поискового запроса.

Ради интереса теперь можем вывести значение нашей сессионной cookie, для этого вместо <script>alert()</script> в URL надо подставить другой код: <script>alert(document.cookie)</script>

С этим я уже предоставлю поиграться вам самостоятельно. 🙂

Найдя ошибку, стоит обратиться к разработчикам — они ее исправят.

Способов закрыть ошибку довольно много. Экранировать текст — не единственный из них. Еще можно запретить самому JavaScript видеть некоторые cookie. Для этого у cookie есть специальный параметр “http only”. Если он выставлен в TRUE, JavaScript никак не сможет узнать, что такая cookie вообще выставлена и не сможет ее прочитать и передать злоумышленнику даже в том случае, если ему удастся найти XSS на вашем проекте.

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

Если Вам интересно знать больше про тестирование безопасности, хочется лучше разобраться в устройстве клиент-серверной архитектуры, понять и отточить самые эффективные способы поиска уязвимостей на настоящем веб-приложении, приходите на мой курс “Тестирование безопасности”. Вся необходима информация есть в моем профиле.

Вас ждет только полезная и нужная теория без воды и большое количество практических примеров и заданий. Вы будете исследовать множество веб-страниц, напичканных самыми разными уязвимостями. Итоговой работой станет большое исследование либо вашего рабочего проекта, либо одного из веб-приложений таких гигантов как Google, Facebook, Twitter и так далее.

Что такое межсайтовый скриптинг (XSS) и XSS-атаки?

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

Атаки XSS нацелены на код (также известный как скрипт) веб-сайта, который выполняется в браузере пользователя, а не на сервере, где располагается данный сайт. Если вы стали жертвой подобной атаки, в ваш браузер был внедрен вредоносный скрипт, угрожающий безопасности вашего ПК. Существует бесконечное множество видов атак межсайтового скриптинга, большинство из которых нацелены на кражу конфиденциальных данных, переадресацию пользователя на подконтрольные хакерам сайты или на манипуляцию компьютера в интересах злоумышленников.

Как происходит атака межсайтового скриптинга?

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

Как распознать атаку межсайтового скриптинга?

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

Как устранить уязвимость межсайтового скриптинга?

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

Как избежать межсайтового скриптинга
  • Установите качественное антивирусное решение на свой компьютер
  • Настройте автоматическое обновление всех сторонних программ
  • Загрузите инструмент для сканирования веб-сайтов на предмет наличия в коде уязвимостей типа XSS
Защититесь от межсайтового скриптинга

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

Что отражает XSS (межсайтовый скриптинг)? Учебник и примеры

Твиттер WhatsApp Фейсбук Реддит LinkedIn Эл. адрес

В этом разделе мы расскажем об отраженных межсайтовых сценариях, опишем влияние отраженных XSS-атак и объясним, как найти отраженные XSS-уязвимости.

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

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

Предположим, что на веб-сайте есть функция поиска, которая получает введенный пользователем поисковый запрос в параметре URL:

https://insecure-website.com/search?term=gift

Приложение повторяет указанный поисковый запрос в ответе на этот URL:

Вы искали: подарок

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

https://insecure-website.com/search?term=

Этот URL приводит к следующему ответу:

Вы искали:

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

ЛАБОРАТОРИЯ

УЧЕНИК Отражение XSS в HTML-контекст без кодирования

Влияние отраженных XSS-атак

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

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

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

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

Подробнее
Эксплуатация уязвимостей межсайтового скриптинга

Отраженный XSS в различных контекстах

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

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

Подробнее
Контексты межсайтового скриптинга

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

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

Проверка отраженных XSS-уязвимостей вручную включает следующие шаги:

  • Проверка каждой точки входа. Протестируйте отдельно каждую точку входа для данных в HTTP-запросах приложения. Сюда входят параметры или другие данные в строке запроса URL-адреса и тексте сообщения, а также путь к файлу URL-адреса. Он также включает заголовки HTTP, хотя XSS-подобное поведение, которое может быть вызвано только определенными заголовками HTTP, на практике может быть непригодным для использования.
  • Отправка случайных буквенно-цифровых значений. Для каждой точки входа отправьте уникальное случайное значение и определите, отражено ли это значение в ответе. Значение должно быть спроектировано таким образом, чтобы выдержать большую часть проверки ввода, поэтому оно должно быть достаточно коротким и содержать только буквенно-цифровые символы. Но он должен быть достаточно длинным, чтобы случайные совпадения в ответе были маловероятными. Обычно идеально подходит случайное буквенно-цифровое значение длиной около 8 символов. Вы можете использовать числовые данные Burp Intruder [https://portswigger.net/burp/documentation/desktop/tools/intruder/payloads/types#numbers] со случайно сгенерированными шестнадцатеричными значениями для генерации подходящих случайных значений. И вы можете использовать опцию grep payloads Burp Intruder, чтобы автоматически помечать ответы, содержащие отправленное значение.
  • Определить контекст отражения. Для каждого места в ответе, где отображается случайное значение, определите его контекст. Это может быть текст между тегами HTML, внутри атрибута тега, который может быть заключен в кавычки, внутри строки JavaScript и т. д.
  • Проверка полезной нагрузки-кандидата. В зависимости от контекста отражения протестируйте первоначальную полезную нагрузку XSS-кандидата, которая вызовет выполнение JavaScript, если она будет отражена в ответе без изменений. Самый простой способ протестировать полезные нагрузки — отправить запрос в Burp Repeater, изменить запрос, чтобы вставить полезную нагрузку-кандидата, отправить запрос, а затем просмотреть ответ, чтобы увидеть, сработала ли полезная нагрузка. Эффективный способ работы — оставить исходное случайное значение в запросе и поместить потенциальную полезную нагрузку XSS до или после него. Затем установите случайное значение в качестве условия поиска в представлении ответов Burp Repeater. Burp выделит каждое место, где появляется поисковый запрос, что позволит вам быстро найти отражение.
  • Проверка альтернативных полезных нагрузок. Если полезная нагрузка-кандидат XSS была изменена приложением или полностью заблокирована, вам потребуется протестировать альтернативные полезные нагрузки и методы, которые могут обеспечить работающую XSS-атаку, в зависимости от контекста отражения и типа выполняемой проверки ввода. . Дополнительные сведения см. в разделе контексты межсайтовых сценариев
    • .
  • Протестируйте атаку в браузере. Наконец, если вам удастся найти полезную нагрузку, которая работает в Burp Repeater, перенесите атаку на реальный браузер (вставив URL-адрес в адресную строку или изменив запрос в представлении перехвата Burp Proxy, и посмотрите, внедренный JavaScript действительно выполняется. Часто лучше всего выполнить какой-нибудь простой JavaScript, например alert(document.domain) , который вызовет видимое всплывающее окно в браузере, если атака будет успешной.

Общие вопросы об отраженном межсайтовом сценарии

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

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

Что хранится XSS (межсайтовый скриптинг)? Учебник и примеры

Твиттер WhatsApp Фейсбук Реддит LinkedIn Эл. адрес

В этом разделе мы объясним сохраненные межсайтовые сценарии, опишем влияние сохраненных XSS-атак и объясним, как найти сохраненные XSS-уязвимости.

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

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

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

POST/сообщение/комментарий HTTP/1.1 Хост: уязвимый-website.com Длина содержимого: 100 postId=3&comment=Этот+сообщение+было+чрезвычайно+полезным.&name=Carlos+Montoya&email=carlos%40normal-user.net

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

Это сообщение было очень полезным.

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

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

комментарий=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

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

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

ЛАБОРАТОРИЯ

УЧЕНИК Сохраненный XSS в HTML-контексте без кодирования

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

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

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

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

Подробнее
Эксплуатация уязвимостей межсайтового скриптинга

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

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

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

Подробнее
Контексты межсайтового скриптинга

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

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

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

Точки входа в обработку заявки включают:

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

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

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

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

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

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

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

No related posts.