Burp Suite. Аудит наличия уязвимостей

Аудит.

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

Этапы аудита.

Burp Scanner выполняет несколько отдельных этапов аудита. Они разделены на три области:

• Пассивная фаза
• Активная фаза
• Этапы анализа JavaScript

Выполнение нескольких этапов в каждой области позволяет Burp:

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

Типы проблем.

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

Проблемы делятся на типы в зависимости от типа сканирования:

• Passive –проблемы, которые можно обнаружить только путем проверки обычных запросов и ответов приложения. Например, сериализованные объекты в сообщениях HTTP.
• Light active – выявляются с помощью небольшого количества дополнительных запросов. Например, совместное использование ресурсов между источниками (CORS), которое доверяет произвольным источникам.
• Medium active –могут быть обнаружены путем отправки запросов, которые приложение может считать вредоносными. Например, внедрение команды ОС.
• Intrusive active - обнаруживаются с помощью запросов, которые несут более высокий риск повреждения приложения или его данных. Например, SQL-инъекция.
• JavaScript analysis – их можно выявить путем анализа JavaScript, который приложение выполняет на стороне клиента. Например, межсайтовый скриптинг на основе DOM. Обнаружение этих проблем часто является ресурсоемким на машине, на которой работает Burp. Эти проблемы также могут быть классифицированы как «Passive» (для автономных проблем на основе DOM) или «Medium Active» (для отраженных и сохраненных вариантов).

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

• Host level - это проблемы, возникающие на уровне службы HTTP хоста, на которой выполняется приложение. Например, разрешительная флэш-междоменная политика.
• Request level - проблемы, возникающие на уровне отдельного запроса. Например, подделка межсайтовых запросов.
• Insertion point level - проблемы, возникающие на уровне точки вставки в запросе. Например, путь к файлу.

Точки вставки.

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

В следующем примере показан запрос с выделением некоторых типов точек вставки:

Burp Scanner проверяет точки вставки индивидуально, внедряя полезные нагрузки в каждую точку вставки по очереди, чтобы проверить обработку приложением этого ввода.

Кодирование данных в точках вставки.

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

Например, к стандартным параметрам тела применяется другое кодирование:

К параметрам в данных JSON:

И к параметрам, содержащим данные в XML:

Burp Scanner также обнаруживает, когда приложение использует другие типы кодирования, которые не привязаны к типу точки вставки, например Base64:

Вложенные точки вставки.

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

Burp Scanner способен обнаруживать это поведение и автоматически применять те же уровни кодирования к полезным нагрузкам:

Изменение расположения параметров.

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

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

Однако некоторые средства защиты приложения, такие как Web-WAF, могут применяться только к исходному типу параметра.

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

Например, если полезные данные отправляются в параметре строки запроса URL, Burp может отправить полезную нагрузку в параметре body и cookie:

Автоматическая обработка сеанса.

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

Когда Burp выполняет аудит отдельного запроса, он начинает с определения кратчайшего пути для получения запроса из начальной точки сканирования:

​

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

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

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

​

Или потому, что единственными токенами сеанса являются куки, которые обычно могут использоваться несколько раз:

​

Или потому что, хотя запрос содержит и куки, и токены CSRF, токены CSRF можно использовать повторно:

​

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

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

​

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

В этой ситуации самый надежный способ повторно выдать запрос на аудит - всегда возвращаться в исходное местоположение и пройти полный путь до этого запроса:

​

После того как Burp определил наиболее эффективный способ повторной передачи запроса, он проводит аудит.

Выполняя различные проверки, Burp периодически отслеживает ответы приложения, чтобы убедиться, что текущий сеанс поддерживается.

Если Burp положительно подтверждает достоверность сеанса, то он устанавливает контрольную точку на проверках, которые были полностью завершены.

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

Например:

​

Дублирование проблем на целевом сайте.

Сканер Burp использует различные методы, чтобы минимизировать дублирование усилий и сообщения о дублирующих проблемах.

Консолидация часто возникающих пассивных проблем.

Некоторые пассивно обнаруженные проблемы могут существовать во многих различных местах в приложении из-за подхода к разработке или повторно используемого шаблона страницы (подделка межсайтовых запросов или междоменный сценарий).

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

Обработка часто встречающихся точек вставки.

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

Это cookie, и параметры cachebuster, которые помещаются в строки запроса URL-адреса для предотвращения кэширования, но не обрабатываются приложением на стороне сервера.

Выполнение аудита этих точек в каждом запросе приводит к избыточным нагрузкам.

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

Анализ JavaScript.

Burp Scanner анализирует JavaScript, содержащийся в ответах приложений, для выявления широкого спектра уязвимостей на основе DOM. Для этого он использует комбинацию статического и динамического анализа:
Статический анализ - это анализирует код JavaScript для построения абстрактного синтаксического дерева (AST). Динамический анализ - загружает ответ во встроенный браузер. Он внедряет полезные данные в DOM в местах, которые потенциально контролируются злоумышленником, и выполняет JavaScript в ответе. Статический и динамический подходы имеют различные сильные и слабые стороны:

Burp Scanner использует преимущества статического и динамического подходов. Где это возможно, он соотносит результаты двух методов и сообщает о проблемах с доказательствами, полученными с использованием обоих методов.

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

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

Обработка ошибок приложения.

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

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

Поскольку часто встречаются единичные ошибки, Burp сначала регистрирует детали ошибки и продолжает сканирование.

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

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

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

Запустим сканирование на целевом объекте:

​

На главной панели можем отслеживать прогресс сканирования:

​

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

​

Эта, тоже довольно скучная часть закончилась, дальше работа с различными видами уязвимостей only

.

Источник