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

2.3.4.9  Использование компонентов с известными уязвимостями.

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

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

2.3.4.10  Непроверенные перенаправления и переходы.

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

НЕ нашли? Не то? Что вы ищете?

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

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

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

·  расшифрование;

·  инспектирование;

·  парсинг;

·  нормализация и хранение;

·  управление сессиями;

·  проверка по политикам безопасности.

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

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

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

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

·  набор критериев в контексте единого правила;

·  встроенный язык программирования с фреймворком по работе с трафиком;

·  интерфейс корреляции пользовательских сигнатур.

2.3.6  Защита от атак типа отказ в обслуживании.

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

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

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

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

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

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

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

·  «сканеры уязвимостей» («Vulnerabilities scanners»);

·  «система контроля инцидентов» («SIEM»);

·  «репутационные сервисы» («Reputation service»);

·  «сервисы противодействия мошенничеству» («Fraud Prevention service»);

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

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

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

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

ГЛАВА 2. РАЗВИТИЕ ЭКРАНОВ ВЕБ-ПРИЛОЖЕНИЙ В БУДУЩЕМ.

3. 

3.1.  Объединение процессов безопасной разработки и технологий экранирования.

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

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

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

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

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6