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

Традиционный 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}).

При этом для функции 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.