Коробочная безопасность веб-приложений. Внутренности Web Application Firewall

Статья посвящена методам защиты веб-приложений, используемым в современных системах защиты веб-приложений (Web Application Firewall -WAF) «из коробки»: машинное обучение, сигнатурный анализ, защита от DoS-атак, выявление нелегетимных запросов и другим.

 

 

 

 

1. Введение

2. Проверка протокола

3. Машинное обучение

4. Сигнатурный анализ

5. Специализированные средства защиты

6. Пользовательские правила выявления нелегитимных запросов

7. Защита от DoS-атак

8. Интегрированность в ландшафт ИБ

9. Заключение

 

 

Введение

Защита веб-приложений становится критически важной для безопасности бизнеса. Известные средства защиты, такие как фаерволы (включая NGFW) и IDS/IPS, уже не могут гарантировать безопасность для общедоступных приложений. Обнаружение аномалий на сетевом уровне, упор на сигнатурный анализ, устаревшие техники анализа и фильтрации — вот лишь неполный перечень причин, по которым стандартные периметровые средства защиты стали небезопасными. К тому же такие системы имеют слишком широкие возможности, сводящиеся к контролю защищенности всей корпоративной сети. Это усложняет их администрирование, в котором они постоянно нуждаются.

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

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

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

 

Проверка протокола

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

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

Обычно применяются следующие ограничения:

• требования RFC;
• длина и количество заголовков, параметров;
• временные рамки;
• проверка JSON, XML сущностей;
• отсутствие недопустимых значений.

  

Машинное обучение

Данный механизм защиты является ключевым, и именно на него делают основную ставку производители Web Application Firewall при разработке и продвижении. Машинное обучение эталонной модели представляет из себя процесс внесения идентификаторов доступа веб-приложения в специальную модель, с последующим сравнением к ней поступающих запросов. Сопоставление запросов с выученной эталонной моделью помогает предотвращать как известные, так и неизвестные уязвимости.

Механизмы защиты на основе машинного обучения различаются по:

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

 

Характеристика машинного обучения	Примеры
Данные на входе алгоритма обучения	Помимо идентификаторов доступа из запроса пользователя, различные реализации позволяют вносить  дополнительные сведения, которые повышают эффективность обучения. Например, могут учитываться следующие данные: запросы от доверенных узлов (зона тестирования); тип параметра: dynamic, static, hidden, read-only; ответы веб-приложения.
Алгоритм обучения	Сердце машинного обучения, математический аппарат, нацеленный на обнаружение аномалий в самом глубоком понимании прикладного обеспечения. Например, Метод опорных векторов (Support Vector Machine) Случайный лес (Random forest) Нейронные сети (Neural Networks) Скрытая модель Маркова (Hidden Markov Model)
Способ принятия решения	Во избежание рекурсивного обучения в машинном обучении должны применяться понятные критерии готовности элемента к внесению его в эталонную модель. Например,  это могут быть следующие критерии: время обучения; количество запросов, содержащих обучаемый элемент; пороги энтропии элемента.
Техника оптимизации модели	В ходе цикла разработки защищаемое веб-приложение постоянно меняет свою модель поведения. Несоответствие выученной эталонной модели с реальной приводит к блокировке клиентских запросов. Для того чтобы этого не случалось, каждый механизм машинного обучения снабжается техникой по оптимизации эталонной модели. Могут использоваться следующие техники: Интерфейс ручной корректировки модели Привлечение “учителя” для машинного обучения Эвристический анализ запросов нарушающих текущую модель, с последующей её оптимизацией
Возможности конфигурирования	Машинное обучение — это сложный совокупный процесс, необходимость в конфигурировании которого может зависеть как от количественных показателей трафика, так и от качественных характеристик веб-приложения. Например, может возникнуть потребность в конфигурировании: максимального времени обучения; порогов срабатывания; способа принятия решения; математических параметров алгоритма обучения.
Формат эталонных моделей	Машинное обучение может быть разработано для построения модели: Позитивной Негативной Так же, в зависимости от обучения, модель может содержать различные объекты, в типичной реализации оптимально считается содержать: Идентификатор ресурса (URI/URL) Параметры прикладных сущностей (HTTP, XML/JSON entity) Идентификатор сессии (Cookie)

 

Сигнатурный анализ

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

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

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

 

Специализированные механизмы защиты

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

К примеру, рассмотрим упоминавшийся ранее механизм защиты «машинное обучение эталонной модели». Он не гарантирует защиты в том случае, если возможно произвести атаку, контекст которой лежит в заданных пределах отклонения от эталонной модели. Происходит это потому, что данный механизм защиты не имеет возможности определить тип воздействия на веб-приложение. Тип нелегитимного воздействия может определяться с помощью сигнатурного анализа, однако атака, использующая 0day-уязвимость, с легкостью преодолеет такой защитный механизм. Таким образом возможность появления False-Negative событий для каждого из механизма защиты вполне осязаема, тогда как вероятность угрозы проведения атаки, которая будет комбинировать несколько условий обхода различных механизмов защиты, становится на порядок меньше. К примеру, комбинированным условием обхода двух выше рассмотренных механизмов защиты является атака, эксплуатирующая 0day-уязвимость, контекст которой не нарушает отклонения от эталонной модели машинного обучения.

Для снижения вероятности False-Negative событий современные WAF не ограничиваются комбинированием двух вышерассмотренных механизмов защиты. Их количество может достигать нескольких десятков, но в отличие от механизма машинного обучения задача исследования этих алгоритмов существенно более узка; зачастую она сводится к обнаружению конкретного типа атак. Такие механизмы защиты носят названия по типу атаки на веб-приложение, которую они обнаруживают. В зависимости от реализации WAF они могут быть как-либо сгруппированы в общей политике безопасности или разнесены в отдельные ее части.

Рассмотрим специализированные механизмы защиты, используемые современными WAF, для обнаружения наиболее распространенных атак на веб-приложения. ( https://www.owasp.org/index.php/Top_10_2013-Top_10 )

1. Injection (Внедрение кода)

Возможность инъекции возникает, когда веб-приложение посылает недостаточно проверенные данные из запроса клиента на вход интерпретатору команд смежной функциональной системы, в общей информационной. Целью атаки могут быть следующие смежные системы: СУБД, операционная система, LDAP-сервер, XPath-интерпретатор и прочие. Это позволяет злоумышленникам манипулировать смежными функциональными системами.

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

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

2. Broken Authentication and Session Management (некорректнаяаутентификацияиуправлениесеансами)

Возможность нарушения управления сессиями возникает вследствие неправильной разработки данного функционала в веб-приложении. Позволяет злоумышленникам компрометировать идентификаторы сессий (например, cookies) с целью получить несанкционированный доступ к веб-приложению с правами другого пользователя.

Обнаружение происходит за счет слежения за идентификаторами сессии.

1. Определение допустимых идентификаторов сессии. Если в запросе найдены ранее неизвестные идентификаторы сессий или значение этих идентификаторов отличается от допустимого значения, запрос признается нелегитимным.
2. Фиксация read-only идентификаторов сессии. При нахождении в запросе измененного идентификатора сессии, который по логике веб-приложения не может изменяться на стороне клиента, запрос признается нелегитимным.
3. Контроль клиентов на предмет подмены идентификаторов сессии. При нахождении в запросе идентификатора сессии, принадлежащего другому клиенту, запрос признается нелегитимным.
4. Определение попыток перебора идентификаторов сессии. При превышении объективно возможного порога запросов в секунду с разными идентификаторами сессий от одного клиента запросы признаются нелегитимными.

Также существуют техники проактивной защиты:

1. криптографическая подпись идентификаторов сессии;
2.  шифрование идентификаторов сессии.

3. Cross-SiteScripting (XSS, межсайтовое выполнение сценариев)

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

Для защиты от XSS используются следующие техники.

1. Токенезация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. При нахождении валидных для синтаксиса языка программирования токенов запрос клиента признается потенциально опасным.
2. Внедрение Content Security Policy (CSP). CSP-заголовок — относительно новый способ обеспечения безопасности HTTP-коммуникаций. Данный заголовок для каждого ответа определяет возможные источники ресурсов, из которых может состоять веб-страница, отображаемая браузером клиента. Некоторые WAF обладают техникой автоформирований правил CSP.
3.  Анализ ответов. Содержание ответа сравнивается с принятыми из запроса данными. При обнаружении однозначных данных в паре запрос-ответ транзакция признается нелегитимной.
4. Внедрение в ответы веб-приложения специального JavaScript-кода, контролирующего отображение страницы в браузере клиента, особенно эффективно при определении DOM-based XSS.
5. Создается группа сигнатур, характеризующих попытки межсайтового исполнения сценариев. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.

4. Insecure Direct Object References (Небезопасные прямые ссылки на объекты)

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

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

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

5. Security Misconfiguration (Небезопасная конфигурация)

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

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

6. Sensitive Data Exposure (Утечкауязвимыхданных)

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

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

 7. MissingFunctionLevelAccessControl (Отсутствие контроля доступа к функциональному уровню)

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

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

8. Cross-Site Request Forgery (CSRF, подделкамежсайтовыхзапросов)

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

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

 9. UsingComponentswithKnownVulnerabilities (Использование компонентов с известными уязвимостями)

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

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

10.UnvalidatedRedirectsandForwards (Непроверенные перенаправления и переходы)

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

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

 

Пользовательские правила выявления нелегитимных запросов

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

• расшифрование;
• инспектирование;
• парсинг;
• нормализация и хранение;
• управление сессиями;
• проверка по политикам безопасности.

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

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

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

Примеры реализации:

• набор критериев в контексте единого правила;
• встроенный язык программирования с фреймворком по работе с трафиком;
• интерфейс корреляции пользовательских сигнатур.

 

Защита от DoS-атак

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

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

Первый уровень защиты от атак типа «Отказа в обслуживании» в WAF — это механизм определения инфицированных клиентов. Он частично заимствован из решений ориентированных на предотвращение мошенничества, где проверка клиентов является одной из ключевых функций. Проверка осуществляется путем внедрения в ответы веб-приложения специального JavaScript-кода, который сканирует окружение клиентского браузера на предмет возможных вредоносных программ. Если JavaScript обнаруживает такие программы на стороне клиента, такие клиенты попадают в отдельный список пользователей, которые будут блокироваться при обнаружении DoS-атаки. Тем самым снижается возможность проведения атаки типа «Распределенный отказ в обслуживании» с помощью бот-сетей.

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

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

 

Интегрированность в ландшафт ИБ

Эффективность средства защиты информации в общем ландшафте информационной безопасности предприятия может многократно усилиться, если эти средства защиты будут связаны друг с другом. Поэтому важно, чтобы такие продукты как Web Application Firewall имели широкие интеграционные возможности с другими системами информационной безопасности. На сегодняшний день WAF могут быть интегрированы со следующими классами систем и сервисов:

• «сканеры уязвимостей» («Vulnerabilities scanners»);
• «система контроля инцидентов» («SIEM»);
• «репутационные сервисы» («Reputation service»);
• «сервисы противодействия мошенничеству» («Fraud Prevention service»);

Наиболее полезной является интеграция со сканерами уязвимостей —таким образом реализуется функция «Виртуального обновления» («Virtual Patching»), позволяющая автоматизировать контроль над безопасностью веб-приложения. Сканер будет находить уязвимости, формировать отчет, а WAF на его основе сформирует соответствующие правила безопасности.

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

Репутационные сервисы, специализируются на выявлении подозрительных IP-адресов из числа общего глобального пула. В базу входят IP-адреса выходных точек анонимной сети TOR, анонимных proxy-серверов, рассылающих спам, фишинговых и подозрительных ресурсов. Также в базе может содержаться обезличенная информация от организаций, использующих WAF по IP-адресам, с которых происходит нарушение их политик безопасности.

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

 

Заключение

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

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

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

1. Продуктивные веб-приложения созданы и живут в цикле безопасной разработки.  
2. Установлен Web Application Firewall. WAF закрывает веб-приложение от известных, но еще не закрытых в цикле разработке уязвимостей, сдерживает эксплуатацию неизвестных.
3. Функционирует центр безопасности. Производится постоянный мониторинг и тюнинг WAF. Сочлененные правильным образом технологии, процессы и люди, готовы начать реализацию дополнительных контрмер.