Хранимые, отображаемые и dom-based xss: выявление и блокирование

Avoiding cross-site scripting vulnerabilities with Veracode.

Veracode provides leading application security solutions that help to protect the software that is critical to business operations. Built on a cloud-based platform, Veracode’s comprehensive testing methodologies allow developers and administrators to test for vulnerabilities throughout the development process, from inception through production. From tools for the developers IDE to static analyses and web vulnerability scanners, Veracode provides on-demand, SaaS-based services that enable organizations to embed security testing into development without sacrificing agility or speed.

Fixing cross-site scripting errors in applications involves three steps:

• Applications must validate data input to the web application from user browsers.
• All output from the web application to user browsers must be encoded.
• Users must have the option to disable client-site scripts.

Veracode’s testing services can quickly scan control and data flow for an application and accurately identify cross-site scripting and other flaws in code that is built in-house or acquired from third-parties. Scan results are returned quickly – usually within four hours – and include a step-by-step remediation plan that helps to accelerate fixes and prioritize efforts.

Общая классификация XSS

Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.

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

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

DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:

1. Злоумышленник создает URL-адрес, который заранее содержит вредоносный код, и отправляет его по электронной почте или любым другим способом пользователю.
2. Человек переходит по этой ссылке, зараженный сайт принимает запрос, исключая вредоносную строку.
3. На странице у пользователя выполняется сценарий, в результате чего загружается вредоносный скрипт и злоумышленник получает cookies.

Как эксплуатируется уязвимость

Конечно, когда вы просто пишете какой-то код, трудно представить, что вы напишете в строке </script> и не заметите проблем. Как минимум, подсветка синтаксиса даст вам знать, что тег закрылся раньше времени, как максимум, написанный вами код не запустится и вы будете долго искать, что произошло. Но это не является основной проблемой с этой уязвимостью. Проблема возникает там, где вы вставляете какой-то контент в Javascript, когда генерируете HTML. Вот частый кусок кода приложений на реакте с серверным рендерингом:

В </script> может появиться в любом месте, где данные поступают от пользователя или из других систем. не будет менять такие строки при сериализации, потому что они полностью соответствуют формату JSON и Javascript, поэтому они просто попадут на страницу и позволят злоумышленнику выполнить произвольный Javascript в браузере пользователя.

Другой пример:

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

Но на закрывающем теге </script> приколы не заканчиваются. Опасность представляет и открывающий тег <script>, если перед ним в любом месте есть символы , которые в обычном HTML обозначают начало многострочного комментария. Причем в этом случае вам уже не поможет подсветка синтаксиса большинства редакторов.

Что видит здоровый человек и большинство подсветок синтаксиса в этом коде? Два тега <script>, между которыми находится параграф.

Что видит больной парсер HTML5? Он видит один (!) незакрытый (!) тег <script>, содержащий весь текст со второй строчки до последней.

Я до конца не понимаю, почему это так работает, мне понятно лишь, что встретив где-либо символы , парсер HTML начинает считать открывающие и закрывающие теги <script> и не считает скрипт законченным, пока не будут закрыты все открытые теги <script>. То есть в большинстве случаев этот скрипт будет идти до конца страницы (если только кто-то не смог внедрить еще один лишний закрывающий тег </script> ниже, хе-хе). Если вы до этого не сталкивались с подобным, то можете подумать, что я сейчас шучу. К сожалению, нет. Вот скриншот DOM-дерева примера выше:

Самое неприятное, что в отличие от закрывающего тега </script>, который в Javascript может встретиться только внутри строковых литералов, последовательности символов и могут встретиться и в самом коде! И будут иметь точно такой же эффект.

Различные типы уязвимости 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,

Справочная информация

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

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

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

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

XSS уязвимости зарегистрированы и используются с середины 1990-x годов. Известные сайты, пострадавшие в прошлом, включают такие сайты социальных сетей, как ,
,
MySpace,
YouTube,
и др.

XSS Examples

Example 1.
For example, the HTML snippet:

is intended to illustrate a template snippet that, if the variable title has value Cross-Site Scripting, results in the following HTML to be emitted to the browser:

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:

sitting on the other end, at the web server, you will be receiving hits where after a double space is the user’s cookie. If an administrator clicks the link, an attacker could steal the session ID and hijack the session.

Example 2.
Suppose there’s a URL on Google’s site, , which returns HTML documents containing the fragment

i.e., the value of the query parameter q is inserted into the page returned by Google. Suppose further that the data is not validated, filtered or escaped. 
Evil.org could put up a page that causes the following URL to be loaded in the browser (e.g., in an invisible<iframe>):

When a victim loads this page from , the browser will load the iframe from the URL above. The document loaded into the iframe will now contain the fragment

Loading this page will cause the browser to execute evil_script(). Furthermore, this script will execute in the context of a page loaded from www.google.com.

Скрипты

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

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

Перейдем в домашнюю директорию командой и создадим в ней с помощью редактора nano ()файл, содержащий 2 строки:

Чтобы выйти из редактора nano после набора текста скрипта, нужно нажать Ctrl+X, далее на вопрос «Save modified buffer?» нажать Y, далее на запрос «File Name to Write:» нажать Enter. При желании можно использовать любой другой текстовый редактор.

Скрипт запускается командой , т.е. перед именем файла указывает на то, что нужно выполнить скрипт или исполняемый файл, находящийся в текущей директории. Если выполнить команду , то будет выдана ошибка, т.к. оболочка будет искать файл в директориях, указанных в переменной среды PATH, а также среди встроенных команд (таких, как, например, pwd):

Ошибки не будет, если выполнять скрипт с указанием абсолютного пути, но данный подход является менее универсальным: . Однако на данном этапе при попытке выполнить созданный файл будет выдана ошибка:

Проверим права доступа к файлу:

Из вывода команды видно, что отсутствуют права на выполнение. Рассмотрим подробнее на картинке:

Права доступа задаются тремя наборами: для пользователя, которому принадлежит файл; для группы, в которую входит пользователь; и для всех остальных. Здесь r, w и x означают соответственно доступ на чтение, запись и выполнение.

В нашем примере пользователь (test) имеет доступ на чтение и запись, группа также имеет доступ на чтение и запись, все остальные – только на чтение. Эти права выданы в соответствии с правами, заданными по умолчанию, которые можно проверить командой . Изменить права по умолчанию можно, добавив вызов команды umask с нужными параметрами в файл профиля пользователя (файл ~/.profile), либо для всех пользователей в общесистемный профиль (файл /etc/profile).

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

Чтобы выдать права на чтение и выполнение пользователю и группе:

Чтобы запретить доступ на запись (изменение содержимого) файла всем:

Также для указания прав можно использовать маску. Например, чтобы разрешить права на чтение, запись, выполнение пользователю, чтение и выполнение группе, и чтение – для остальных, нужно выполнить:

Будут выданы права :

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

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

Число	Двоичный вид	Права доступа
000	Нет прав
1	001	Только выполнение (x)
2	010	Только запись (w)
3	011	Запись и выполнение (wx)
4	100	Только чтение (r)
5	101	Чтение и выполнение (rx)
6	110	Чтение и запись (rw)
7	111	Чтение, запись и выполнение (rwx)

Выдав права на выполнение, можно выполнить скрипт:

Первая строка в скрипте содержит текст . Пара символов называется Шеба́нг (англ. shebang) и используется для указания интерпретатору, с помощью какой оболочки выполнять указанный скрипт. Это гарантирует корректность исполнения скрипта в нужной оболочке в случае, если у пользователя будет указана другая.

Также в скриптах можно встретить строку . Но, как правило, /bin/sh является ссылкой на конкретный shell, и в нашем случае /bin/sh ссылается на /bin/dash, поэтому лучше явно указывать необходимый интерпретатор. Вторая строка содержит команду , результат работы которой мы видим в приведенном выводе.

Impact of Cross-Site Scripting

When attackers succeed in exploiting XSS vulnerabilities, they can gain access to account credentials. They can also spread web worms or access the user’s computer and view the user’s browser history or control the browser remotely. After gaining control to the victim’s system, attackers can also analyze and use other intranet applications.
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

• Hijack an account.
• Spread web worms.
• Access browser history and clipboard contents.
• Control the browser remotely.
• Scan and exploit intranet appliances and applications.

Планировщик заданий cron

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

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

Где m – минута, h – час, dom – день месяца, mon – месяц, dow – день недели, command – команда, parameters – список параметров. Наглядно этот формат можно представить так:

Например, для того, чтобы в 10 и 30 минут каждого часа каждый день месяца весь год по будням запускать команду, нужно указать следующее:

Более простой пример, каждые 15 минут выполнять команду:

Создадим скрипт для резервного копирования домашней директории пользователя, который будет создавать новый файл бэкапа при каждом запуске:

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

Проверить, что задача добавлена в планировщик, можно командой :

В результате каждый день в 22:00 будет создаваться резервная копия домашней директории пользователя (в приведенном примере для демонстрации запуск скрипта выполняется каждую минуту):

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

Как избежать проблем?

Как вы уже поняли, способа безопасно вставить Javascript в HTML нет. Но есть способы сделать Javascript безопасным для вставки в HTML (почувствуйте разницу). Правда для этого нужно быть предельно внимательным всё время, пока вы пишете что-то внутри тега <script>, особенно если вы вставляете любые данные с помощью шаблонизатора.

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

Остается проблема внедрения символов в строки. В этом случае, как и написано в спецификации, всего-то нужно заменить все «» на «», «» на «», а «» на «». Но беда в том, что если вы выводите какую-то структуру с помощью , то вряд ли вы захотите потом её распарсить еще раз, чтобы найти все строковые литералы и заэкранировать в них что-то. Так же не хочется советовать пользоваться другими пакетами для сериализации, где эта проблема уже учтена, потому что ситуации бывают разными, а защититься хочется всегда и решение должно быть универсальным. Поэтому я бы советовал экранировать символы / и ! с помощью обратного слеша уже после сериализации. Эти символы не могут встречаться в JSON нигде кроме как внутри строк, поэтому простая замена будет абсолютно безопасной. Это не изменит последовательность символов «», но она и не представляет опасности, если встречается сама по себе.

Точно так же можно экранировать и отдельные строки.

Другой совет — не встраивайте в тег <script> ничего вообще. Храните данные в местах, где трансформации для вставки данных однозначны и обратимы. Например, в атрибутах других элементов. Правда смотрится это довольно грязно и работает только со строками, JSON придется парсить отдельно.

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

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

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

Для вызова справки по командам вводим 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» для генерации консольной команды.

Параметры скриптов

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

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

Создадим файл script1.sh следующего содержания:

Выдадим права на выполнение и выполним скрипт с параметрами:

Мы передали 2 параметра, указывающие город и страну, и использовали их в скрипте, чтобы сформировать строку, выводимую командой printf. Также для вывода в строке Hello использовали имя пользователя из переменной USER.

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

При этом нужно доработать скрипт, чтобы в команду printf параметры также передавались в кавычках:

Из приведенных примеров видно, что при обращении к переменной для получения её значения используется символ $. Для того, чтобы сохранить значение переменной просто указывается её имя:

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

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

Рисунок 3. Типы XSS-уязвимостей

Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.):

Традиционные XSS-атаки:

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

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

Также известные как DOM-модели:

1. Отраженные (непостоянные). То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
2. Хранимые (постоянные). Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.

Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.):

Встречаются очень редко, но являются более опасными:

1. Инфраструктура на стороне клиента. Происходит, когда вредоносная составляющая производит какие-либо манипуляции с функционалом браузера, например с его XSS-фильтром и т.п.
2. Инфраструктура на стороне сервера. Возникает, когда веб-сервер некорректно обрабатывает запросы, позволяя модифицировать их.
3. Сеть. Происходит, когда возможно внедриться в связь между клиентом и сервером.

Уязвимости, вызванные пользователем:

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

Обработка ввода на входе/выходе

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

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

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

XSStrike

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

Возможности:

• фаззинг;

• технология взлома контекста;

• интеллектуальная генерация пэйлоадов;

• поддержка методов GET & POST;

• поддержка файлов cookie;

• обнаружение WAF;

• пэйлоады ручной работы для фильтрации и WAF-уклонения;

• скрытое обнаружение параметров.

Пример:

Более подробно про XSStrike на русском можно прочитать здесь.

Тестирование обхода WAF. XSSer vs XSStrike

Здесь указан URL, параметры POST-запроса, использование заготовленного словаря с пейлоадами и задержка в 1 секунду между запросами.

При использовании XSSer со стандартным набором пейлоадов, Nemesida WAF Free заблокировал все атаки, за исключением направленных на старые версии браузеров (например, Internet Explorer 6). Также не были заблокированы запросы, не преставляющие собой реальную атаку, например:

• <xml id=»X»><a><b>955c5ecb3ac1e7ef80ab181ca5d5c7d9;<b></a></xml>

• <DIV STYLE=»width: expression(c5d576195e3d738adcfb2e1f10019443);»>

• <LINK REL=»stylesheet» HREF=»bdde8029cb7599bd5601cb739bab6590″>

Есть символы, используемые в атаках, но отдельно не являющиеся опасными. Их блокировка потенциально может привести к ложным срабатываниям. В Nemesida WAF Free мы разрабатываем качественные сигнатуры для снижения количества ложных срабатываний.

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

Дополнительно применялась мультикодировка —Cem:

В этом случае пейлоад будет по очереди закодирован сначала в String.FromCharCode () (Str), после чего полученная строка будет закодирована в шестнадцатиричный код (Hex). Кодировок можно добавлять и больше, но это будет прямо пропорционально влиять на скорость проверки.

Если сравнивать эффективность XSStrike и XSSer, то мы, скорре, отдадим предпочтение последнему. Хотя в XSStrike есть функция преобразования полезной нагрузки в base64:

Параметр —data отвечает за содержимое тела POST-запроса, —skip позволяет пропустить проверку перед применением пейлоадов, а -e устанавливает кодировку пейлоадов.

Контекст обработки вводимой информации

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

Контекст	Пример кода
Содержание элемента HTML	<div>userInput</div>
Значение атрибута HTML	<input value=»userInput»>
Значение запроса URL	http://example.com/?parameter=userInput
Значение CSS	color: userInput
Значение JavaScript	var name = «userInput»;

Почему контекст – это важно

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

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

In all of the contexts described, an XSS vulnerability would arise if user input were inserted before first being encoded or validated. An attacker would then be able to inject malicious code by simply inserting the closing delimiter for that context and following it with the malicious code.

Код приложения:	<input value=»userInput»>
Вредоносная строка:	«><script>…</script><input value=»
Результат:	<input value=»»><script>…</script><input value=»»>

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

Исправление DOM Cross-site Scripting

Лучший способ исправить межсайтовый скриптинг на основе DOM и повысить безопасность веб-приложений — это использовать правильный метод вывода (приемник). Например, если вы хотите использовать пользовательский input для записи в элемент <div>, не используйте innerHtml, вместо этого используйте innerText/textContent. Это решит проблему, и это правильный путь для устранения уязвимостей XSS на основе DOM.

Всегда плохая идея использовать контролируемый пользователем input в опасных источниках, таких как eval. В 99% случаев это признак плохой или ленивой практики программирования, поэтому просто не делайте этого вместо того, чтобы пытаться дезинфицировать входные данные.

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

Он делает то же самое, но на этот раз он не уязвим к уязвимостям cross-site scripting, основанным на DOM.