С появлением технологий разработки многофункциональных веб-приложений и увеличения числа веб-сервисов возросло количество уязвимостей в этих приложениях. Межсайтовый скриптинг (Cross Site Scripting, CSS или чаще используемая аббревиатура XSS) один из наиболее распространенных типов атак посредством внедрения кода.
Авторы: Ништа Джатана (Nishtha Jatana) – доцент, кафедра Информатики и Проектирования, Технологический институт Махараджа Сураджмал (Maharaja Surajmal Institute of Technology), Нью-Дели, Индия, nishtha.jatana@gmail.com;
Адвития Агравал (Adwiteeya Agrawal), Критика Собти (Kritika Sobti), оба студенты, кафедра Информационных Технологий, Технологический институт Махараджа Сураджмал Нью-Дели, Индия, adwiteeyaagrawal@gmail.com, kritikasobti92@gmail.com;
Аннотация – XSS (межсайтовый скриптинг) – уязвимость в веб-приложении, когда конечный пользователь может передавать простые скрипты как полезные нагрузки (payloads) через необрабатываемые входные параметры. Подобный тип уязвимостей существует уже достаточно давно, однако наша текущая задача – последующее использование обнаруженных уязвимостей. Эта концепция известна как «Пост-эксплуатация XSS», и именно на ней сфокусировано внимание в этой статье. В данном документе представлено углубленное исследование угроз XSS-уязвимостей и упрощенное их применение. Также показаны варианты защитных действий от XSS-атак, которые могут быть применены в качестве мер предосторожности. Далее мы используем одну из уязвимостей и разработаем новый модуль на базе одной из популярных утилит для XSS-атак. Этот модуль можно использовать для вызова через SIP-протокол (Session Initiation Protocol, протокол установления сеанса). Модуль был разработан для нового релиза фреймворка XSSF.
Ключевые слова: XSS, Post-XSS, Атаки, Средства защиты.
1. Введение
С появлением технологий разработки многофункциональных веб-приложений и увеличения числа веб-сервисов возросло количество уязвимостей в этих приложениях. Межсайтовый скриптинг (Cross Site Scripting, CSS или чаще используемая аббревиатура XSS) один из наиболее распространенных типов атак посредством внедрения кода. Суть XSS в следующем: в веб-приложение находится уязвимость, а затем происходит внедрение кода через необрабатываемые входные параметры. Когда легитимный пользователь заходит на инфицированную страницу, происходит вызов вредоносного кода в его браузере. Внедренный код может читать, изменять или передавать любые конфиденциальные данные, к которым есть доступ у браузера: cookies, идентификаторы сессий (session tokens) и т. д.
XSS-уязвимости (Cross-site Scripting (XSS) – OWASP, см. раздел Ссылки) существуют уже достаточно давно. Детальное описание XSS можно найти в обзоре Shanmugam и Ponnavaikko от 2008 года (см. раздел Ссылки). В статье основной акцент делается на пост-эксплуатацию XSS-уязвимостей, то есть атаках, которые могут быть проведены после нахождения уязвимости или в сочетании с поиском подобных уязвимостей. В Разделе 2 мы расскажем об основных функциях некоторых полезных и популярных утилит, используемых для нахождения XSS-уязвимостей и выполнения XSS-атак. В Разделе 3 мы классифицируем XSS-атаки (постоянные (хранимые), непостоянные (отраженные), основанные на DOM-модели). В Разделе 4 будут описаны некоторые из последних и наиболее интересных уязвимостей найденных в веб-приложениях, а также методы их использования. В Разделе 5 мы перечислим несколько защитных средств, которые можно реализовать как на стороне сервера, так и на стороне клиента для защиты веб-страницы или приложения от XSS-уязвимости. В Разделе 6 мы представим концепцию и код нового модуля, разработанного для вызовов через протокол VoIP (Voice over Internet Protocol), используя XSS-уязвимость. В конце мы подведем итоги и представим идеи и мысли для дальнейшей работы в этой области.
2. Популярные утилиты для нахождения и эксплуатации XSS-уязвимостей
В этом разделе мы кратко рассмотрим несколько популярных фреймворков для нахождения XSS-уязвимостей в веб-приложениях и их последующего использования. Они инжектируют полезные нагрузки (payloads) и выполняют скрипты на уязвимой странице.
2.1 Xenotix
Xenotix (Abraham, 2012, см. раздел Ссылки), по существу, является утилитой для тестирования на проникновение в систему, используемой для пост-эксплуатации XSS-уязвимостей. В его базе есть более 450 полезных нагрузок, включая даже такие, которые могут обойти основные XSS-фильтры, используемые для защиты веб-разработчиками. Полезные нагрузки можно использовать как в ручном, так и в автоматическом режиме. Можно, к примеру, собирать данные вводимые пользователем на инфицированной странице или загружать вредоносные исполняемые файлы на компьютер жертвы без ее ведома. Когда пользователь затем просматривает инфицированную страницу, java-апплет client.jar получит доступ к командной строке его системы. Про помощи команды echo, в файл winconfig.vbs (файл скриптов Visual basic) в директорию temp (%temp%) записываются скрипты, а затем cmd.exe запускает windonfig.vbs, который загрузит вредоносный исполняемый файл определенный злоумышленником в URL. Далее произойдет переименование файла в update.exe и его запуск. Еще один эксплоит, предлагаемый Xenotix, - установка обратной оболочки (reverse shell) (Hammer, 2006, см. раздел Ссылки) на компьютер жертвы для получения доступа к его системе.
Несмотря простоту Xenotix, утилита имеет несколько ограничений. Например, данные по нажатым клавишам могут собираться только на инфицированной странице, а при загрузке файлов на компьютер пользователя могут запускаться только 16-битные исполняемые файлы. К тому же, у пользователя каждый раз при загрузке файла или атаке через обратную оболочку всплывают сообщения, поскольку приложение использует самоподписанные апплеты.
2.2 XSSF
Целью проекта XSSF является выявления потенциальных угроз, связанных с XSS-уязвимостями (Tomes, 2011 и xssf - Cross-Site Scripting Framework - Google Project Hosting; см. раздел Ссылки). Основная функция заключается в создании коммуникационного канала (или XSSF-туннеля) с браузером жервы (у которого есть XSS уязвимость) для выполнения различных атак, каждая из которых оформлена отдельным модулем. Существует огромное количество модулей, например, для кражи файлов, вызовов по Скайпу с iphone, сканирования сети и многие другие, которые могут быть реализованы для эксплуатации уязвимых веб-приложений.
Основной механизм работы XSSF – создание туннеля, включая список всех id жертвы в тот момент, когда пользователь заходит на страницу с XSS-уязвимостью. Затем злоумышленник определяет браузер пользователя, ищет подходящий эксплоит и налаживает сеанс работы с жертвой. Теперь злоумышленник может получить доступ к компьютеру пользователя. Более продвинутый метод: злоумышленник создает XSSF-туннель и получает доступ к локальному хосту с удаленной машины, а затем пользуется всеми его функциями. Также, используя XSSF, интегрированный с консолью Metasploit (Offensive Security Ltd., 2012, см. раздел Ссылки) можно использовать эксплоит для браузера на сайте с XSS-уязвимостью для получения meterpreter-сессии, а затем и полного доступа к системе. Еще одна особенность XSSF – так называемая «атака на автомате», когда автоматически по очереди исполняются несколько эксплоитов после захода жертвы на уязвимую страницу.
С одной стороны XSSF предлагает множество методов для XSS-атак, однако не предоставляет большого количества методов для нахождения XSS-уязвимостей. Также для работы с XSSF предварительно необходимо ознакомиться с Metasploit.
2.3 BeFF
Beef (Home · beefproject/beef Wiki · GitHub, 2006, см. раздел Ссылки) или Browser Exploitation Framework является мощной утилитой для браузера, при помощи которой можно производить тестирование на проникновение в систему. В приложении используются различные методы для оценки безопасности целевой среды. Фреймворк состоит из модулей управления, использующих простую и в тоже время мощную систему API, что делает всю систему весьма эффективной. Также есть возможность разработки пользовательских модулей.
BeFF подцепляет (hook) один или несколько браузеров для запуска определенных модулей управления и последующих атак против системы изнутри контекста браузера (browser context). У различных браузеров, по-видимому, есть различные контексты безопасности, к каждому из которых можно применить свой уникальный набор атак. Фреймворк позволяет тестировщику безопасности выбрать определенные модули (в режиме реального времени) для каждого браузера и, соответственно, каждого контекста.
BeFF – мощная утилита для выполнения различных атак, эксплуатирующих XSS-уязвимости, например, browser fingerprinting (сбор информации о браузере), удерживание захваченного браузера (persistence), сбор информации о сети, работа с DNS (DNS enumeration), сканирование портов и IRC NAT Pinning и т. д.
3. Типы XSS-атак
Существует три вида XSS-атак:
Все уязвимости веб-страниц и веб-приложений могут быть отнесены к одному из трех видов, упомянутых выше. Каждый из видов атак описывается ниже при помощи диаграмм, которые наглядно показывают процесс детектирования и реализации XSS-атаки.
Рисунок 1: Типичный сценарий непостоянной (отраженной) XSS-атаки
Непостоянные (отраженные) атаки (см. рис. 1) осуществляются, когда данные предоставляемые веб-клиентом тут же используются серверными скриптами для генерации страницы с результатами для этого самого клиента. Если пользовательские данные некорректны и содержатся внутри страницы с результатами без кодирования HTML - это позволяет внедриться клиентскому коду в динамическую страницу. Теперь инжектированный код может быть выполнен на стороне сервера, например, на странице с поисковыми результатами или на странице с ошибкой или любой другой странице, которая появляется в ответ на запрос пользователя. Эта страница будет включать в себя часть входных данных, передаваемых серверу как часть запроса. Непостоянные атаки могут быть реализованы не только на веб-страницах, но и, например, при передаче e-mail сообщений или через сторонний веб-сервер. Когда пользователя обманным путем заставляют нажать на вредоносную ссылку или отправить данные специально заполненной формы, инжектируемый код передается на уязвимый веб-сервер, который затем отражается обратно и исполняется в браузере жертвы, поскольку данные поступают с достоверного сервера.
Рисунок 2. Типичный сценарий постоянной (хранимой) XSS-атаки
Постоянные (хранимые) атаки (см. рис. 2) обладают наибольшим потенциалом. При таких атаках вредоносных код хранится на сайте (в базе данных, файловой системе или в другом месте), а затем отображаются посетителю веб-страницы без кодирования с использованием специальных символов HTML. Например, на форумах пользователи могут публиковать сообщения формате HTML.
Рисунок 3. Типичный сценарий атаки, основанной на DOM
Локальные XSS-атаки или атаки, основанные на DOM, заключаются в том, что злоумышленник меняет данные на стороне клиента во время запроса страницы с сервера.
К примеру, если участок кода JavaScript имеет доступ к параметру URL и формирует некий HTML-код на странице, используя эту информацию, которая не закодирована с использованием спецсимволов HTML – возможно, присутствует XSS-дыра, поскольку записанные данные будут заново интерпретированы браузерами, так как HTML-код может содержать дополнительный клиентский скрипт.
4. Пост-эксплуатация XSS-уязвимостей
4.1 Кража данных в Android
Уязвимость, описанная здесь (Cannon, 2013, см. раздел Ссылки), присутствует во фреймворке Android версии 2.2. Брешь может быть использована для получения доступа к файлам на SD-карте в устройстве на платформе Android. Браузер в Android не выводит никаких сообщений, в то время как файл, например, «payload.html» автоматически загружается в /sdcard/download/ payload.html. Можно использовать JavaScript для автоматического открытия этого файла, что приведет к тому, что браузер обновит локальный файл и позволит скрипту получить доступ к файлам, хранящимся на SD-карте. Далее можно передать содержимое файлов обратно на инфицированный веб-сайт. Будучи простым эксплоитом, использующим JavaScript и редиректы, он может поражать телефоны с различными версиями Android. Однако у него есть некоторые ограничения. Например, необходимо заранее знать имя и путь к файлу, к которому мы хотим получить доступ. Поскольку эксплоит не повышает привилегии в системе, с его помощью можно получить доступ только к файлам на SD-карте.
4.2 Некорректная URI-схема и встроенный Webkit-браузер Скайпа в iOS
Эта уязвимость (более детально описана в Kumar, 2011; Purviance, 2011; iPhones Make Automatic Skype Calls | Security Generation, 2010; см. раздел Ссылки) существует в фреймворке iOS. Ее можно использовать для получения доступа к базе данных SQLite адресной книги или совершать звонки при помощи Скайпа. Скайп, разработанный для iOS, использует локальный HTML-файл для отображения сообщений от других пользователей. Проблема заключается в том, что приложение некорректно кодирует информацию, содержащуюся в поле «Full Name», что позволяет злоумышленнику сформировать вредоносный JavaScript-код, который запустится, когда жертва будет просматривать сообщение.
Еще одна проблема кроется во встроенном браузере на базе Webkit, используемый Скайпом. Разработчики добавили URI-схему «file://», позволяющей злоумышленнику получить доступ к файловой системе и прочитать любой файл, доступный в песочнице iOS (iOS application sandbox). Пользуясь лояльной политикой безопасности для сторонних приложений, которые могут выполнять определенные действия, используя URL или URI-схему, злоумышленник может встроить в веб-страницу скрытый iframe, при помощи которого можно совершать звонки в Скайпе (если, конечно, он установлен в системе). JavaScript выглядит примерно так: <iframe src=”skype://1900expensivepremium
number?call”> </iframe>.
4.3 Использование HTML5 API для междоменных вызовов
Эту уязвимость можно использовать только для систем на базе Windows (Kuppan, 2010, см. раздел Ссылки). В HTML5 API есть два способа для совершения междоменных вызовов: Cross Origin Requests и WebSockets. Используя эти механизмы и JavaScript можно соединиться с любым IP-адресом и любым портом (за исключением заблокированных), что делает эти технологии идеальными для создания сканера портов. Можно, к примеру, определить является ли порт открытым, закрытым или находящимся под фильтром. Для этого существуют два свойства: «ready state», которое отображает статус соединения в определенный момент времени и «time duration», которое отображает временной интервал нахождения в состоянии «ready state».
Таким образом, наблюдая за изменениями состояния, мы можем определить тип порта. Поскольку наш сканер работает на уровне приложения, успех сканирования зависит от софта, установленного на целевом хосте. Когда посылается запрос определенному приложению, оно считывает его, но ничего не отвечает, сохраняя сокет открытым, и, возможно, ожидает дополнительные входные запросы или запросы в определенном формате. В этом случае статус определить невозможно. Поскольку можно опознать даже закрытые порты, мы можем сканировать всю сеть, а также определять внутренние IP-адреса.
4.4 Управления Ajax-историей в HTML5
Об этой уязвимости рассказано в (Kotowicz, 2010, см. раздел Ссылки). В HTML5 есть функция window.history.pushState(), которая позволяет получать доступ к страницам и ссылкам без изменения URL. Эта функция создана для AJAX-сайтов для более простого внесения изменений в адресной строке (window location bar) и управления историей. Подобный механизм очень удобен для разработчиков: к примеру, теперь в AJAX-приложениях может быть легко реализована поддержка кнопок Назад/Вперед без использования трюков с идентификатором # в URI-фрагментах. Однако если веб-сайт имеет XSS-уязвимость, злоумышленник может перенаправлять пользователей без каких-либо изменений в адресной строке.
4.5 Доступ к элементу управления WScript ActiveX в Internet Explorer
Настройки безопасности в Internet Explorer позволяют получить доступ элементу управления WScript ActiveX через JavaScript и VBScript. В простейшем приложении показывается как при помощи объекта "WScript.shell" ActiveX можно взаимодействовать с клиентской машиной (Spitzen, 2008, см. раздел Ссылки). При помощи этого элемента управления можно выполнять команды, как и в командной строке, без оповещения пользователя. Используя Shell, можно создавать, удалять или изменять текстовые файлы через WScript.FileSystemObject. В IE7 появилась новая настройка безопасности «Разрешен доступ к источникам данных через домен» (Access data sources across domain), и теперь по умолчанию происходит оповещение пользователя, хочет ли он разрешить скрипту «пообщаться» с другими доменами (файловая система рассматривается как отдельный домен). Однако можно создать и запустить скрипт прямо на диске и, соответственно, обойти эти ограничения.
4.6 File API в HTML5
Эта уязвимость существует в движке Webkit (последняя версия Google Crome), и может использоваться для использования браузера Google Crome в качестве файлового сервера. File API в HTML5 позволяет JavaScript получить доступ к файлу в момент выбора его пользователем (перед закачкой). Помимо улучшения интерфейса закачки, данный механизм может быть использован для кражи файлов во время XSS-атаки. Вы можете создать скрытый элемент input type=file, так что пользователь, сам того не ведая, начнет загружать файл. В этом случае файл, выбранный пользователем в диалоговом окне Открыть, является единственным, к которому можно получить доступ. Хотя input type=file directory - прекрасная возможность, позволяющая пользователю загружать содержимое выбранной директории, к которой может получить доступ злоумышленник.
4.7 Использование XSS-уязвимости для определения координат
Компания Google помимо сбора данных для Google Street View также собирала данные о беспроводных сетях и MAC-адресах роутеров этих сетей, а затем определяла их GPS-координаты. Как описано в (Higgins, 2010, см. раздел Ссылки), XSS-эксплоит можно использовать для получения данных о местонахождении пользователя. Эксплоит может получить MAC-адрес роутера жертвы, а затем использовать Google Maps для определения GPS-координат. Сам по себе роутер и браузер не содержат информацию о местонахождении или GPS-данные, однако, когда вы зайдете на вредоносную страницу, злоумышленник через AJAX может получить MAC-адрес роутера, а затем, используя сервисы Google, узнать о вашем местонахождении (получить примерные GPS-координаты) на основе полученного MAC-адреса.
4.8 NAT PINNING – IRC через HTTP
Сами Камкар (Samy Kamkar) рассказал об этой уязвимости в своей статье (Kamkar, 2010, см. раздел Ссылки). При такой XSS-атаке вредоносная страница незаметно заставляет роутер или фаервол пользователя пробросить любой порт обратно на его машину. Когда жертва кликает по вредоносной ссылке, содержащей скрытую форму для соединения с ресурсом http://attacker.com:6667 (IRC-порт), происходит сабмит формы без ведома пользователя. Далее создается HTTP-соединение с (фальшивым) IRC-сервером злоумышленника, который находится в режиме ожидания. Роутер жертвы видит «IRC соединение» (даже если клиент использует HTTP-соединение) и попытку установить сессию при помощи DCC chat. Протокол DCC (Direct Client-to-Client) является суб-протоколом IRC, позволяющий обмениваться файлами и текстовыми сообщениями минуя сервер. Для взаимодействия через DCC chat необходим открытый локальный порт на клиентской машине, к которому подсоединяется удаленный абонент. Поскольку роутер блокирует все входящие подключения, принимается решение о перенаправлении всего трафика на порт DCC chat для того, чтобы злоумышленник смог обойти NAT (NAT traversal), соединиться и пообщаться с жертвой. Однако злоумышленник должен указать конкретный порт, к примеру, 21-й порт (FTP). Теперь роутер будет производить переадресацию с этого порта на систему жертвы, и у злоумышленника появляется возможность соединиться и произвести атаку.
4.9 Использование эксплоитов для браузеров
При таких атаках можно, например, эксплуатировать стек браузера и запускать вредоносный шелл-код или открывать meterpreter-сессию, используя эксплоиты, нарушающие целостность информации в памяти в связке с XSS. Остальные эксплоиты могут возвращать meterpreter-сессию без непосредственного воздействия на стек браузера. Например, самоподписанный java-апплет можно использовать для загрузки и выполнения вредоносных исполняемых файлов.
5. Новый модуль для реализации XSS-атаки
В этом разделе мы представим новый модуль на базе XSSF (cross site scripting framework).
5.1 Концепт модуля
Здесь мы расскажем о концепции нового модуля, который будет создан на базе XSSF и будет эксплуатировать XSS-уязвимость для совершения вызова по протоколу VoIP.
Elastix PBX (Elastix Freedom to communicate, 2006, см. раздел Ссылки) – PBX-сервер, позволяющий осуществлять коммуникации через протокол VoIP. Приложение доступно для свободной загрузки по адресу http://www.elastix.org /index.php/en/downloads.html. Программное обеспечение имеет веб-интерфейс для конфигурирования сервера и доступно с любой машины в сети. Для получения доступа к серверу в браузере нужно указать адрес https://IP/ (IP – адрес сервера). Наш модуль работает с версией Elastix PBX 2.2. 20 марта 2012 года об XSS-уязвимости в веб-интерфейсе сервера сообщил «Martin Tschirsich».
Согласно его информации, уязвимость содержится в файле www/html/recordings/ misc/callme_page.php. При помощи этой уязвимости SIP-клиент может вызвать определенное расширение. Мы разработали модуль, эксплуатирующий данную уязвимость и вызывающий расширение, для фреймворка XSSF на языке Ruby. Во время запуска модуля жертва видит подсказку с вызовом.
Когда пользователь посещает страницу, которая уже скомпрометирована злоумышленником, его имя отображается в списке на панели в XSSF-фреймворке. Если у жертвы установлено соединение с сервером посредством SIP-клиента, злоумышленник может запустить этот модуль и реализовать атаку.
Рисунок 4. Скриншот после выполнения модуля
5.2 Код модуля
5.2.1 Инициализация модуля
Рисунок 5. Инициализация модуля
5.2.2 Скрипт, посылаемый жертве
Рисунок 6. Скрипт, посылаемый жертве
5.3 Этапы выполнения атаки
Необходимо, чтобы сервер Elastix 2.2.0 PBX и жертва находились в одной подсети. Также жертва должна законнектиться к серверу при помощи SIP-клиента. Далее злоумышленнику необходимо установить XSSF внутри Metasploit. Вначале пользователь должен перейти по следующей ссылке (это необходимо для вызова расширения): https://IP_address_of_Elastix/recordings/misc/callme_page.php?action=c&callmenum=Extension@from-internal/h
Общая схема атаки выглядит так:
6. Способы защиты от XSS-уязвимостей
В современном мире онлайн сервисы набирают все большую популярность и, соответственно, веб-приложения играют все более важную роль. Однако в то же время растет и количество уязвимости в этих приложениях. Сегодня, когда веб-безопасность может быть легко скомпрометирована, необходимо предпринимать больше усилий по защите от подобных атак. Существуют различные способы для предотвращения угроз XSS-атак. Подобные механизмы (XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP, 2012, см. раздел Ссылки) можно реализовать как на стороне сервера, так и на стороне клиента.
6.1 Защита на стороне сервера
Для защиты от XSS-уязвимостей разработчики могут предпринять различные шаги. Основная концепция: не доверять входным данным (включая cookies), посылаемым пользователем. Перед тем, как открыть доступ, необходимо произвести тщательную проверку и валидацию. Безопасность cookies, как говорилось в статье Роберта Хафнер (Robert Hafner) (Hafner, 2009, см. раздел Ссылки), может быть реализована путем ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly, использованием SSL. Никогда не следует хранить конфиденциальные данные в cookies. Еще один безопасный способ: запретить использование скриптов со стороны клиента сайта. Заголовки Content-Security-Policy также можно использовать для защиты от использования XSS-эксплоитов. Также необходимо кодировать управляющие HTML-символы, JavaScript, CSS и URL’ы перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: filter_sanitize_encoded (для кодирования URL), htmlentities (для фильтрации HTML), filter_sanitize_magic_quotes (применяется функция addslashes()). Эти фильтры проверяют входные параметры, посылаемые пользователем, JavaScript, POST-запросы и предотвращают запуск скриптов. Помимо этого существует несколько библиотек, которые кодируют входные данные: OWASP Encoding Project (доступен на Google Code), HTML Purifier или Htmlawed для PHP Anti-XSS Class. Для .Net приложений: AntiSamy API для .Net, для Java: XSS-HTML-Filter.
6.2 Защита на стороне клиента
Конечные пользователи также могут предпринять определенные шаги для защиты от XSS-атак. Например, можно установить расширения для браузера, которые будут проверять поля форм, URL’ы, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox; NotScripts для Crome и Opera. В Internet Explorer 8 для решения этой задачи имеется встроенная функция.
7. Выводы и идеи для дальнейшей работы
В 21 веке веб-приложения стали неотъемлемой частью нашей жизни. Однако часто они являются уязвимыми к определенным атакам. В данном документе мы рассмотрели один из видов уязвимостей и способы их последующей эксплуатации. XSS-атаки являются преобладающими среди атак, когда происходит внедрение кода, и уязвимости, позволяющие совершать подобные действия, могут стать основой мощных эксплоитов. В более серьезных атаках XSS может сочетаться с использованием других типов уязвимостей. В данной статье мы рассмотрели некоторые наиболее распространенные атаки. Мы привели список утилит для нахождения XSS-уязвимостей и их последующей эксплуатации, а также познакомили вас с ключевыми функциями этих утилит. Затем мы рассмотрели различные виды XSS-атак вместе с концепцией каждой из них. Мы разработали новый модуль на основе XSSF, который совершает VoIP-вызовы. Код самого модуля вместе с базовой концепцией и алгоритмом работы также представлен в этой статье. В предпоследнем разделе мы рассмотрели некоторые способы защиты от XSS, которые могут быть реализованы как на стороне сервера, так и на стороне клиента. По мере появления новых приложений и функций, будут появляться новые уязвимости и виды атак. Мы намереваемся продолжить эту работу, комбинируя критические уязвимости вместе XSS и создавая новые модули, которые могут быть использованы другим программным обеспечением и фреймворками.
Ссылки
(n.d.). Retrieved from http://santoshdudhade.blogspot.in/2012/07/xssf-v22-cross-site-scripting-framework.html
Abraham, A. (2012). Detecting and Exploiting XSS with Xenotix XSS Exploit Framework. Retrieved from Club Hack 2012: http://www.clubhack.com/2012/event/technical-briefings/detecting-and-exploiting-xss-with-xenotix-xss-exploit-framework/
Cannon, T. (2013, november 23). Android Data Stealing Vulnerability | thomascannon.net. Retrieved 2013, from thomascannon.net: http://thomascannon.net/blog/2010/11/android-data-stealing-vulnerability/
Cross-site Scripting (XSS) - OWASP. (n.d.). Retrieved February 2013, from www.owasp.org: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
Elastix Freedom to communicate. (2006). Retrieved from http://www.elastix.org/index.php/en/downloads.html.
Hafner, R. (2009, August). How to create totally secure cookies. Retrieved from teamtreehouse.com: http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies
Hammer, R. (2006). Inside-Out Vulnerabilities, Reverse Shells. Retrieved from www.sans.org: http://www.sans.org/reading_room/whitepapers/covert/inside-out-vulnerabilities-reverse-shells_1663
Higgins, K. J. (2010). Hack Pinpoints Victim's Physical Location. Retrieved from http://www.darkreading.com/security/news/222200541/hack-pinpoints-victim-s-physical-location.html
Home · beefproject/beef Wiki · GitHub. (2006). Retrieved from github.com: https://github.com/beefproject/beef/wiki
iPhones Make Automatic Skype Calls | Security Generation. (2010, November 10). Retrieved 2013, from www.securitygeneration.com: http://www.securitygeneration.com/tech/iphones-make-automatic-skype-calls/
Kamkar, S. (2010, January). NAT Pinning: Penetrating routers and firewalls from a web page (forcing router to port forward). Retrieved from http://samy.pl/natpin/
Kotowicz, K. (2010, November). THE WORLD. ACCORDING TO KOTO. Retrieved from blog.kotowigz.net: http://blog.kotowicz.net/2010/11/xss-track-got-ninja-stealth-skills.html
Kumar, M. (2011, September 20). iPhone Skype XSS Vulnerability Lets Hackers Steal Phonebook [Video] - Hacking News. Retrieved 2013, from thehackernews.com: thehackernews.com/2011/09/iphone-skype-xss-vulnerability-lets.html
Kuppan, L. (2010). Port Scanning with HTML5 and JS-Recon. Retrieved from http://blog.andlabs.org: http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html
Offensive Security Ltd. (2012). Introduction - Metasploit Unleashed. Retrieved from www.offensive-security.com: http://www.offensive-security.com/metasploit-unleashed/Introduction
Purviance, P. (2011, September 19). XSS in Skype for iOS « Superevr. Retrieved from superevr.com: https://superevr.com/blog/2011/xss-in-skype-for-ios/
Shanmugam, J., & Ponnavaikko, D. M. (2008). Cross Site Scripting-Latest developments and solutions: A survey. International Journal of Computational Mathematics, 1(2). Retrieved from http://www.emis.de/journals/IJOPCM/files/IJOPCM(Vol.1.2.2.S.08).pdf
Spitzen, I. (2008). Using WScript.shell to interact with the Client machine. Retrieved from http://www.visualwebgui.com/Developers/KB/tabid/654/article/using_wscript_shell_to_interact_with_the_client_machine_by_mark_reed/Default.aspx
Tomes, T. (2011, July ). PaulDotcom. Retrieved from http://pauldotcom.com/2011/07/xssf-expanding-the-attack-surf.html
XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP. (2012). Retrieved February 2013, from www.owasp.org: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
xssf - Cross-Site Scripting Framework - Google Project Hosting. (n.d.). Retrieved February 2013, from code.google.com: http://code.google.com/p/xssf/
Сбалансированная диета для серого вещества