Контакты
Подписка
МЕНЮ
Контакты
Подписка

RVP: защита Web-приложений на базе технологий SAST

RVP: защита Web-приложений на базе технологий SAST

В рубрику "Защита информации" | К списку рубрик  |  К списку авторов  |  К списку публикаций

RVP: защита Web-приложений на базе технологий SAST

Одной из наиболее популярных тенденций защиты приложений нынешнего десятилетия является технология виртуального патчинга (VP, Virtual Patching). Данная технология позволяет защитить приложение от эксплуатации имеющихся в нем известных уязвимостей на уровне внешней системы обнаружения вторжений (IDS – Intrusion Detection System). Это достигается за счет принудительного применения политик защиты, направленных на блокировку вредоносного трафика, специфичного для каждой из уязвимостей. Технология виртуального патчинга предполагает разработку правил детектирования атаки для каждой выявленной в приложении уязвимости и их внедрение в IDS до того времени, пока уязвимости не будут устранены в коде приложения.
Владимир Кочетков
Руководитель отдела исследований по анализу
защищенности приложений, компания Positive Technologies

Традиционный VP для Web-приложений

Традиционный подход к автоматизации создания виртуальных патчей для Web-приложений заключается в предоставлении информации WAF (Web Application Firewall) о каждой обнаруженной с помощью средств статического анализа (далее SAST – Static Application Security Testing) уязвимости, включающей:

  • класс уязвимости;
  • уязвимую точку входа в Web-приложение (URL или его часть);
  • значения дополнительных параметров HTTP-запроса, при которых атака становится возможной;
  • значения уязвимого параметра – носителя вектора атаки;
  • множество символов или слов, появление которых в векторе приведет к эксплуатации уязвимости.

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

  • для доказательства наличия уязвимости средству SAST достаточно обнаружить один из возможных векторов атак на нее. Для эффективного патчинга уязвимости необходимо защититься от всех возможных векторов, которые в общем случае невозможно сообщить на сторону WAF, поскольку их множество бесконечно;
  • информация об опасных символах бесполезна в том случае, если на пути от точки входа до уязвимой точки выполнения (Vulnerable Execution Point – VEP) вектор атаки подвергается промежуточным преобразованиям, изменяющим его грамматику (например, Base-64/URL/HTML/etc-кодирование).

Эти недостатки приводят к тому, что технология VP, ориентированная на защиту от частных случаев, не позволяет защититься от всех возможных атак на уязвимости, обнаруженных с помощью SAST. К примеру, для приведенного кода на рис. 1 (C#, ASP.NET) построение корректного патча невозможно из-за промежуточных преобразований потоков данных в 10 и 15-й строках.


Для того чтобы устранить эти недостатки, технологию VP необходимо расширить в следующих направлениях:

  • SAST должен сообщать WAF полную информацию о всех преобразованиях, которым подвергаются вектор и переменные условий успешной атаки на пути от точки входа до VEP таким образом, чтобы WAF имел возможность самостоятельно вычислить их значения в уязвимой точке, исходя из значений параметров HTTP-запроса;
  • для детектирования атаки должны использоваться не эвристические, а формальные методы, основанные на строгом доказательстве каких-либо утверждений и покрывающие общий случай вместо частных.

Runtime Virtual Patching

В основе технологии виртуальных патчей времени выполнения (далее RVP – Runtime Virtual Patching) лежит используемая модель анализируемого приложения под названием "граф потоков вычисления" (Computation Flow Graph – CompGF). Данная модель строится во время анализа кода приложения в результате его абстрактной интерпретации в семантике, схожей с традиционными символическими вычислениями. Вершины данного графа содержат формулы-генераторы, задающие множество допустимых значений всех потоков данных, присутствующих в соответствующих точках выполнения. Эти потоки называются аргументами точки выполнения. Одним из свойств CompFG является его конкретизируемость – возможность вычислить множества конкретных значений всех потоков данных в любой точке выполнения приложения, задав значения для всех входных параметров. Например, для рассмотренного выше примера формула для VEP (рис. 2) будет выглядеть следующим образом: CustomDecode(condition) ? "secret" ? param ? CustomDecode({xss-vectors-text}).


В контексте защиты Web-приложений роль IDS выполняет межсетевой экран Web-приложения (WAF – Web Application Firewall), а виртуальные патчи легко формулируются в терминах его языка описания сигнатур атак. Очевидно, что в этом случае их качество напрямую зависит от возможности такого языка точно описывать критерии детектирования каждой из атак. Разработка сигнатур атак для реализации виртуальных патчей вручную, как правило, предполагает существенный объем кропотливой работы, в результате чего повышается вероятность ошибки и существенно замедляется время реагирования на факт обнаружения очередной уязвимости в коде приложения. В связи с этим еще одной популярной тенденцией является интеграция средств анализа защищенности приложений c WAF, позволяющая автоматизировать генерацию виртуальных патчей по результатам анализа защищенности.

При этом для функции CustomDecode (если ее исходный код был доступен во время анализа) в соответствующей вершине CompFG будет выведена формула, описывающая цепочку преобразований Base64-URL-Base64: (FromBase64Str (UrlDecodeStr (FromBase64Str argument))).

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

  1. Для каждой найденной уязвимости из вершины CompFG, описывающей VEP, выводятся три формулы:
    • условие достижимости уязвимой точки;
    • условие достижимости всех ее аргументов;
    • множества значений всех ее аргументов и грамматик, которым они соответствуют.
  2. Отчет об обнаруженных уязвимостях (включая информацию, описанную в предыдущем шаге) выгружается в виде кода на специальном унифицированном языке.
  3. При необходимости этот отчет может быть откорректирован вручную.
  4. Код на DSL компилируется в бинарный модуль, работающий на стороне классического WAF и позволяющий вычислять формулы из отчета перед обработкой каждого HTTP-запроса.

На этапе эксплуатации при каждом HTTP-запросе WAF делегирует его обработку бинарному модулю RVP, который выполняет следующие шаги:

  • вычисляются формулы условий – достижимости уязвимой точки и значений всех ее аргументов;
  • если формулы всех условий вычислились в ложное значение, то это значит, что данный HTTP-запрос не может привести приложение в VEP с опасными значениями всех ее аргументов, в этом случае RVP возвращает обработку запроса основному модулю WAF;
  • значения всех аргументов VEP вычисляются по алгоритму, сочетающему конкретные вычисления с абстрактной интерпретацией, что позволяет выделить в вычисленном значении "загрязненные" фрагменты, полученные в результате каких-либо преобразований входных данных;
  • исходя из вычисленных значений, в зависимости от класса уязвимости, осуществляется формальное доказательство атаки (например, в случае инъекций полученное значение каждого из аргументов VEP разбивается на токены (рис. 3) в соответствии с его грамматикой, и если на каждый из "загрязненных" участков пришлось более одного токена, то это и является формальным признаком атаки);
  • обработка запроса передается в основной модуль WAF вместе с результатами детектирования.


***

Реализованный таким образом подход к защите приложения на основе результатов анализа защищенности его кода обладает рядом существенных преимуществ по сравнению с традиционным VP: l за счет описанного выше формального подхода и возможности учитывать все промежуточные преобразования выходных данных устранены все рассмотренные недостатки традиционного VP; l формальный подход также исключает возможность появления ложных срабатываний первого рода (False-Positive), при условии корректной реализации токенайзеров для каждой из поддерживаемых грамматик; l отсутствие какого-либо влияния на функциональность Web-приложения, поскольку защита реализуется не просто в соответствии с ней, а на ее же основе.

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

  • 0% при обработке запросов, не приводящих в VEP;
  • 10% при обработке запросов, приводящих в VEP, но не являющихся атакой;
  • 7% при обработке запросов, приводящих в VEP и являющихся атакой.

Таким образом, в среднем время обработки HTTP-запросов с помощью RVP сравнимо со временем их обработки модулями традиционной защиты WAF.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #4, 2017
Посещений: 7031

Приобрести этот номер или подписаться
  Автор

Владимир Кочетков

Владимир Кочетков

Руководитель отдела исследований по анализу
защищенности приложений, компания Positive Technologies

Всего статей:  1

В рубрику "Защита информации" | К списку рубрик  |  К списку авторов  |  К списку публикаций