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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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, помимо того, что запрещает использование легальных последовательностей символов внутри тега <script> и не дает никакого способа их экранирования в рамках HTML, также советует следующее:

Что можно перевести как «Всегда экранируйте последовательности «» как «», «» как «», а «» как «», когда они встречаются в строковых литералах в ваших скриптах и избегайте этих выражений в самом коде». Эта рекомендация меня умиляет. Тут делается сразу несколько наивных предположений:

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

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

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

Скрипты

Для выполнения нескольких команд одним вызовом удобно использовать скрипты. Скрипт – это текстовый файл, содержащий команды для 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, поэтому лучше явно указывать необходимый интерпретатор. Вторая строка содержит команду , результат работы которой мы видим в приведенном выводе.

Input & Output так называемый Источник & Приемник

Логика, лежащая в основе DOM XSS, заключается в том, что ввод от пользователя (источника) направляется в точку выполнения (приемник). В предыдущем примере нашим источником был document.baseURI, а приемником был document.write.

Однако вам нужно понять, что DOM XSS появится, когда источник, которым может управлять пользователь, будет использоваться в опасном приемнике.

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

Ниже приведен список источников и приемников, которые обычно предназначены для атак DOM XSS

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

Популярные приемники

• HTML модифицированные приемники
  • document.write
  • (element).innerHTML
• HTML модифицированные для изменения поведения
• Приемники связанные с выполнением кода
  • eval
  • setTimout / setInterval
  • execScript

Тестирование

Проверка автоматической генерации пейлоадов

Набор пейлоадов, которые предлагает XSSer, находится в файле ./core/fuzzing/vectors.py и записан в виде JSON. Сам список имеет вид:

{ ‘payload’:»»»<iframe<?php echo chr(12)>onload=PAYLOAD></iframe>»»»,’browser’:»»»Not Info»»»}

Если сравнивать с XSStrike, то у него было несколько наборов:

• базовые теги (img, iframe и т.д.)

• обработчики событий (onload, onerror, onmouseover и т.д.)

• функции (например confirm()) и т.д.

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

Во время тестирования все применяемые пейлоады кодируются в URL-Encode, а результаты автоматически записываются в текущей папке в файл XSSreport.raw, если не указано иное.

Проверка поиска уязвимых сайтов для XSS средствами Google Dork

Данная функция позволяет инструменту проводить поиск уязвимых страниц в Интернете, используя GoogleDork-запросы. В процессе поиска XSSer будет искать страницы по указанным критериям и, если найдет, отправит пейлоад для проверки наличия XSS-уязвимости. В самом простом случае запрос может выглядеть так:

где:

—De — поисковой движок (DuckDuckGo, Yahoo, Bing)

-d — содержимое GoogleDork-запроса

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

Роль скриптов в СЕО

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

Дело в том, что каждый скрипт — это определенная нагрузка на сервер (если он выполняется в браузере — на браузер). Чрезмерное их количество может привести к тому, что сайт будет зависать и тормозить. Это негативно скажется на поведении посетителей. А, как известно, поведенческие факторы играют одну из главных ролей при ранжировании страниц в поисковой выдаче. Чтобы не портить поведенческие факторы своей площадки, необходимо убрать все лишние скрипты. Оставлять стоит только самые «нужные». Именно поэтому все специалисты в области СЕО рекомендуют не использовать совсем или использовать по минимуму анимационные и динамические элементы. Да, это красиво, но неэффективно с точки зрения производительности.

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

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

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

• общая производительность сайта;

• скорость загрузки страниц.

СЕО — это многогранный процесс, состоящий из множества «мелких» деталей. Поэтому каждой из них нужно уделять достаточно внимания, в том числе и скриптам сайта.

Список полезных команд

Список встроенных команд интерпретатора: helpПомощь по команде: <команда> —helpМануал по команде: man <команда>Версия команды: <команда> —versionСписок доступных оболочек: cat /etc/shellsСписок пользователей и их оболочек: cat /etc/passwdТекущая директория: pwdСписок файлов текущей директории: ls -laТекущий пользователь: idПеременные среды: setВерсия ОС: cat /etc/os-releaseВерсия ядра: uname -aПолучить привилегии суперпользователя: sudo su -Установка программы в Debian: apt install mcПосмотреть утилизацию(загрузку): topСвободное место: df -hСколько занимает директория: du -ks /var/logКонфигурация сетевых интерфейсов: ifconfig -aОбъем оперативной памяти: free -mИнформация о блочных устройствах(дисках): lsblkИнформация о процессорах: cat /proc/cpuinfoСписок установленных пакетов: apt list —installedСписок и статус сервисов: service —status-allПерезапуск сервиса: service apache2 restartСкачать файл: wget https://www.gnu.org/graphics/gplv3-with-text-136×68.pngПолучить веб-страницу по URL: curl https://www.google.comПоказать задания планировщика: crontab -lРедактировать задания планировщика: crontab -eВывести новые сообщения в системном логе: tail -f /var/log/syslogПодсчитать количество строк в выводе команды: <команда> | wc -lИзменить права доступа к файлу (разрешить выполнение всем): chmod a+x <файл>Список процессов: ps -efПроверить, запущен ли процесс: ps -ef | grep <процесс>Перейти в предыдущий каталог: cd -Завершить процесс (сигнал kill): kill -9Удаление файла: rm <имя файла>Удаление директории: rm -rf <имя директории>Редактировать файл: nano <имя_файла>Топ 10 процессов по использованию памяти: ps aux | awk ‘{print $6/1024 » MB\t\t» $11}’ | sort -nr | head

Когда лучше обрабатывать строку

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

У обработки до записи в базу есть несколько недостатков:

• Мы не можем узнать реальную длину строки, поскольку ООО «Три кота» — это 14 символов, но ООО &quot;Три кота&quot; — уже 24 символа.
• Помимо HTML данные из базы иногда нужно подставлять куда-то ещё, например в word/excel/pdf файлы, где может не быть никаких мнемоник. Придётся декодировать все данные в исходный вид.

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

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

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

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

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

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

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

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

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

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

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

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

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

Veracode Can Help You Protect Against XSS Attacks

Secure coding practices can help avoid introducing XSS vulnerabilities. However, no developer is always aware of every potential site for flaws or vulnerabilities. Veracode’s Developer Training and eLearning tools can teach secure coding practices while Veracode Security Labs provides hands-on training to enable all developers to write secure code and embed security into their projects from the beginning.

Veracode Discovery tests web applications, discovering and inventorying Internet-facing applications and scanning for vulnerabilities, including SQL injection vulnerabilities, CSRF attacks, LDAP injections, and mobile application flaws. Veracode Dynamic Analysis efficiently scans web applications, finds vulnerabilities, and guides developers to address issues, all before your application goes live.

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

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

Контекст	Пример кода
Содержание элемента 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=»»>

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

Типы 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. Часто происходит в результате социальной инженерии, когда пользователь случайно запускает вредоносный код в своем браузере.

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

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

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

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

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

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

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

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

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

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