[eXISten]

О чем эта статья? Эта статья рассказывает об особенности использования таких атак как SQL Injection и XSS (Cross Site Scripting) в одной атаке – атаке SiXSS.
Для кого написана эта статья? Статья рассчитана на новичков в этой области, но предполагает, что у читателя есть кое-какие знания. То есть, хотя бы общее понятие об атаках SQL-injection и XSS. Но все же, я постараюсь все понятно расписать, и даже если читатель плохо ориентируется в этих атаках, то он все равно поймет, как сделать то, о чем говорится в статье.
Ну и естественно, не забывайте об уголовном кодексе и уголовной ответственности за свои действия. Автор статьи не несет ответственность, за возможный причиненный ущерб.
И все-таки, что же такое SiXSS, и как их осуществить? Как я уже писал выше, это – совместное использование двух видов атак. Может возникнуть вопрос: а зачем это вообще надо – это совмещение? Есть SQL-inj, есть XSS – это разные атаки, и их не нужно совмещать!
Но не тут то было. Многие люди сталкивались с таким: беглый поиск уязвимостей на web-сайте не принес успеха. Вроде, XSS не видно, скриптов на сайте минимум…Но! Мы нашли уязвимый запрос, выводящий запрошенную страничку из базы данных:

http://site.net/article.php?article=8

На ум приходит тест на SQL injection. Попробуем так:

http://site.net/arti...cle=8 AND 1=2/*

Запрос ничего не вернул.

http://site.net/arti...cle=8 AND 1=1/*

Выполнился нормально. Это значит, что перед нами SQL инъекция. Далее, по сценарию, взломщик пытается вытащить необходимые данные из БД. Однако, что мы будем делать, если нет конкретной информации относительно базы данных, или конфигурация базы данных запрещает доступа к файлам? Время идет, а продвижения во взломе нет.
Тут-то к нам на помощь и приходит SiXSS.

В языке SQL, который используется для работы с базами данных, есть оператор UNION, который выполняет роль «скрепления» двух запросов. Кто знаком с SQL, тот понял, о чем я говорю, но все равно поясню:

http://site.net/news...,DATABASE(),3/*

Запрос извлекает новость, с идентификатором 1, и в этом же запросе извлекает информацию о базе данных.
Однако, UNION SELECT, кроме этого, даёт возможность выводить в окно браузера произвольный текст. Благодаря этому, как раз, мы и можем успешно провести SiXSS. В начале, разумеется, нужно подобрать количество полей, т.к. количество извлекаемых из БД полей должно быть равно количеству извлекаемых полей после UNION.

http://site.net/arti... select 1,2,3/*

Это может нам помочь, если UNION не фильтруется. Что если, мы внедрим javascript через SQL inj? Ведь он отобразится в браузере, благодаря особенности UNION SELECT.

http://site.net/]http://site.net/article.php?article=8+union+select+alert("Vulnerability");/*

Вот и алерт – окно с сообщением «Vulnerability». Значит, если немного доработать скрипт, мы получаем полноценную пассивную XSS уязвимость – отправку cookies прошедшего по такой ссылке человека к нам на сниффер, например. Что и требовалось доказать – теперь мы можем работать с этой уязвимостью, как и с обычной XSS.

Хотя, все не так просто, ведь вышесказанное – идеальный вариант «идеальной» уязвимости. К примеру, что если на сервере включена директива gpc_magic_quotes, которая фильтрует кавычки? Не беда. Чтобы обойти эту фильтрацию, можно использовать кодирование в HEX, с добавлением 0x, или ASCII. Можно использовать сторонние программы, можно использовать скрипт, или средства той же БД MySQL или иную (функция char() и hex()).

Итак, будем считать, что мы кодировали в HEX выражение «alert("Vulnerability");». Теперь попробуем подставить это значение в уязвимый запрос:

Код
http://site.net
/article.php?article=8+union+select+0x3C7363726970743E616C6572742822536958535322293B3C2F73637
26970743E

Все, с magic_quotes мы разобрались. Теперь поговорим о других недостатках такой «конструкции». Они такие же, как и у обычной пассивной XSS-ки: человек может и не пройти по ссылке (длинный и непонятный урл), или же у человека отключено выполнение javascript. Рассмотрим возможности атаки при каждом из таких недостатков. Начнем с первого.

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

Если ты читал статьи по XSS, и неоднократно применял эту уязвимость на практике, то ты должен иметь понятие о том, как используют пассивные XSS в POST-запросах. Все же, постараюсь объяснить. К примеру, данные передаются уязвимому скрипту методом POST. Чтобы было более понятно, сделаем вот такую HTML-форму:

Код
<_HTML>
<_BODY ONLOAD="send.submit();"
<_FORM NAME=send ACTION=xss.php METHOD=POST>
<_INPUT TYPE=hidden NAME=alertik VALUE="<_scrpt>alert('XSS');">




И вот такой скрипт, с именем xss.php:

Код
echo $_POST['alertik']
?>

Итак, если мы передадим уже известный javascript, то алерт появится, но в адресной строке будет отображаться только адрес уязвимого скрипта – никаких GET параметров. То есть, мало подозрительного.

Ядовитую ссылку же подсовывают так: пишут скрипт, который отсылает запрос уязвимому скрипту, и заливают его на какой-нибудь хост. Затем, дают ссылку на такой скрипт жертве. И жертва, ничего не подозревая, проходит по ссылке. Данные, POST запросом отсылаются уязвимому скрипту. В результате – XSS удался.

Таким образом, можно сторонним скриптом и перенаправить жертву на ядовитую ссылку с нашим SiXSS. Пример такого скрипта на PHP, который редиректит браузер на другую страницу:

Код
header("Location: ссылка")
?>

Отлично, еще одна проблема позади. Но вернемся к отключенному JS.

На Securitylab я прочитал про интересный метод. Благодаря UNION SELECT, мы ведь не только javascript можем выводить на страницу, но и HTML. Так вот, можно без проблем подделать страницу с вводом логина и пароля, с отсылкой их скрипту, который будет писать все данные в файл – то есть простой фишинг. Неплохо, правда? Вставлять такой код можно аналогично вышеописанному – сложностей не должно возникнуть.

Подведу итог статьи. Ничего «сверхнового» в ней нет, все те же SQL-inj и XSS. Надеюсь, ты почерпнул из нее что-то для себя.
Указание на какие-либо тематические ошибки (если они есть) приветствуется.

P.S. В статье запрещены теги типа "script", поэтому ---> они были заменены на "scrpt"
Это было сделано чтобы не угробить столь замечательный форум.