Критерии оценки экрана веб-приложений (стр. 4 )

2.3.4  Специализированные механизмы.

Специализированные механизмы защиты Эффективность фильтрующих средств защиты существенно зависит от степени перекрытия одних и тех же угроз различными механизмами. Объясняется это тем, что всегда существует некоторая вероятность, в пределах которой исследуемые атаки могут остаться незамеченными для конкретного алгоритма защиты. Вероятность обнаружения атаки, если ее исследуют множество различных алгоритмов, резко понижается. Это наглядно демонстрируется при попытках теоретически спроектировать обход механизмов защиты экрана веб-приложений. К примеру, рассмотрим упоминавшийся ранее механизм защиты «машинное обучение эталонной модели». Он не гарантирует защиты в том случае, если возможно произвести атаку, контекст которой лежит в заданных пределах отклонения от эталонной модели. Происходит это потому, что данный механизм защиты не имеет возможности определить тип воздействия на веб-приложение. Тип нелегитимного воздействия может определяться с помощью сигнатурного анализа, однако атака, использующая 0day-уязвимость, с легкостью преодолеет такой защитный механизм. Таким образом возможность появления ложно-негативных событий для каждого из механизма защиты вполне осязаема, тогда как вероятность угрозы проведения атаки, которая будет комбинировать несколько условий обхода различных механизмов защиты, становится на порядок меньше. К примеру, комбинированным условием обхода двух выше рассмотренных механизмов защиты является атака, эксплуатирующая 0day-уязвимость, контекст которой не нарушает отклонения от эталонной модели машинного обучения. Для снижения вероятности ложно-негативных событий современные экраны веб-приложений не ограничиваются комбинированием двух вышерассмотренных механизмов защиты. Их количество может достигать нескольких десятков, но в отличие от механизма машинного обучения задача исследования этих алгоритмов существенно более узка; зачастую она сводится к обнаружению конкретного типа атак. Такие механизмы защиты носят названия по типу атаки на веб-приложение, которую они обнаруживают. В зависимости от реализации WAF они могут быть как-либо сгруппированы в общей политике безопасности или разнесены в отдельные ее части. Рассмотрим специализированные механизмы защиты, используемые современными экрана веб-приложений, для обнаружения наиболее распространенных атак на веб-приложения.

2.3.4.1  Внедрение кода.

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

1.  Токенизация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. Если валидные для синтаксиса целевой системы токены найдены, запрос клиента признается потенциально опасным.

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

3.  Создается группа сигнатур, характеризующих попытки манипуляции с целевой системой. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным

2.3.4.2  Некорректная аутентификация и управление сеансами.

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

1.  Определение допустимых идентификаторов сессии. Если в запросе найдены ранее неизвестные идентификаторы сессий или значение этих идентификаторов отличается от допустимого значения, запрос признается нелегитимным.

2.  Фиксация read-only идентификаторов сессии. При нахождении в запросе измененного идентификатора сессии, который по логике веб-приложения не может изменяться на стороне клиента, запрос признается нелегитимным.

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

4.  Определение попыток перебора идентификаторов сессии. При превышении объективно возможного порога запросов в секунду с разными идентификаторами сессий от одного клиента запросы признаются нелегитимными.

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

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

2.  шифрование идентификаторов сессии.

2.3.4.3  Межсайтовое выполнение сценариев.

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

1.  Токенезация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. При нахождении валидных для синтаксиса языка программирования токенов запрос клиента признается потенциально опасным.

2.  Внедрение Content Security Policy (CSP). CSP-заголовок — относительно новый способ обеспечения безопасности HTTP-коммуникаций. Данный заголовок для каждого ответа определяет возможные источники ресурсов, из которых может состоять веб-страница, отображаемая браузером клиента. Некоторые WAF обладают техникой автоформирований правил CSP.

3.  Анализ ответов. Содержание ответа сравнивается с принятыми из запроса данными. При обнаружении однозначных данных в паре запрос-ответ транзакция признается нелегитимной.

4.  Внедрение в ответы веб-приложения специального JavaScript-кода, контролирующего отображение страницы в браузере клиента, особенно эффективно при определении DOM-based XSS.

5.  Создается группа сигнатур, характеризующих попытки межсайтового исполнения сценариев. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.

2.3.4.4  Небезопасные прямые ссылки на объекты.

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

1.  Определение попыток перебора объектов. При превышении объективно возможного порога запросов объектов в секунду от одного клиента запросы признаются нелегитимными.

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

3.  Создается группа сигнатур, характеризующих попытки прямого обращения к объектам. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.

2.3.4.5  Небезопасная конфигурация.

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

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

2.3.4.6  Утечка критичных данных.

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

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

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

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

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

2.3.4.8  Подделка межсайтовых запросов.

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