Cross site scripting что это

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

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

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

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

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

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

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

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

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

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

В адресной строке вместо идентификатора (8) добавляем скрипт – ">, в результате чего получаем ссылку такого вида: http://site.ru/catalog?p= ">.

Если страница имеет уязвимости 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, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

Давайте внедрим код “” в элемент формы:

XSS в DOM-модели

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

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

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

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

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

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

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

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

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

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

Метод 1: замена «

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

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

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

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

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

Данный код выведет на экран наше сообщение (в данном случае — «XSS»). Вышеописанный метод очень эффективен для обхода фильтрации magic quotes.

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

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

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

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

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

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

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

Пожалуйста, нажмите href="http://www.google.com/">здесь, чтобы перейти на предыдущую страницу’;
?>

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

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

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

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

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

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

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

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

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

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

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

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

Этот скрипт не требует никаких действий со стороны пользователя. Во втором случае на сайт жертвы внедряется скрытый 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-ng на экране отобразиться консоль приложения:

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

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

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

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

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

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

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

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

Заключение

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

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

Подписывайтесь на каналы "SecurityLab" в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.