МОДЕЛИ И МЕТОДЫ ЗАЩИТЫ ВЕБ-РЕСУРСОВ: СИСТЕМАТИЧЕСКИЙ ОБЗОР Текст научной статьи по специальности «Компьютерные и информационные науки»

Cloud of Science. 2020. T. 7. № 3 http:/ / cloudofscience.ru

Модели и методы защиты веб-ресурсов: систематический обзор

С. А. Лесько

МИРЭА - Российский технологический университет 119454, Москва, пр-т Вернадского, 78

e-mail: lesko@mirea.ru

Аннотация. Представленный обзор посвящен описанию существующих моделей и методов защиты веб-ресурсов и возможностей создания средств автоматизированного обнаружения уязвимостей. Наблюдая общую картину, можно отметить что существуют некоторые сходства между различными, на первый взгляд, типами атак. Например, XSS-атаки по своей основе очень похожи на атаки SQL-инъекциями. Корень проблемы заключается в отсутствии разделения данных и (иногда нескольких) потоков кода. Однако несмотря на корневые сходства между атаками XSS и SQL-инъекциями, может быть трудно применить одну и ту же защиту от данных видов атак из-за технических трудностей. Например, обнаружение XSS-атак может выполняться путем анализа HTTP-ответов, но для атак SQL-инъекциями необходимы другие источники, такие как анализ PHP кода или мониторинг запросов к базе данных во время работы. Учитывая некоторые контекстные сходства в этих видах атак, можно сказать что, разработка унифицированного подхода к защите от них была бы очень полезна. Такие атаки на основе несоответствия контекста возможны из-за отсутствия изоляции пользовательских данных. На основании проведенного обзора можно сделать вывод, что дальнейшее развитие таких методов обнаружения уязвимостей и защиты веб-приложений может пойти по пути соединения возможностей различных методик. Это позволит охватить максимально широкий класс уязвимостей и контролировать полноту их обнаружения, чтобы по итогам автоматического анализа можно было бы дать гарантию отсутствия уязвимостей заданных классов. Ключевые слова: модели и методы защиты Web-ресурсов, использование политик безопасности, анализ входа и выходов, анализ стороны клиента, методы защиты от загрязнения HTTP параметров.

1. Введение

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

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

Такое усложнение выдвинуло новые требования к вопросам безопасности веб-приложений. Известно, что безопасность — это ключевой момент разработки веб-приложения и разработчики должны уделять достаточно внимания этому вопросу.

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

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

Интернет теперь является частью жизни каждого человека, а также основным средством доступа ко многим полезным услугам со строгими требованиями безопасности.

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

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

Такие ошибки могут вызвать серьезные уязвимости безопасности, которые затем могут быть использованы злоумышленниками.

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

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

- уязвимости веб-протоколов могут нарушить защищенность и целостность сеанса связи;

- ошибки в коде веб-приложения могут привести к встраиванию вредоносного содержимого в веб-страницы.

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

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

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

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

- безопасность JavaScript;

- безопасность браузера;

- безопасность веб-приложений;

- анализ веб-протоколов.

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

2. Веб-приложения

2.1. Архитектура Веб-приложений

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

Содержимое страницы может динамически обновляться с использованием JavaScript, слабо типизированного языка сценариев, выполняемого браузером. Код JavaScript может быть включен в веб-страницу и управлять ею, изменяя Document Object Model (DOM), древовидное представление веб-страницы. В работе [1] исследователи представили обобщенную архитектуру любого веб-приложения, откуда выявили все пути проведения различных атак.

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

трафика прозрачны, поэтому протокол HTTP не гарантирует конфиденциальность и целостность связи.

Для защиты обмена данных был разработан протокол HTTP Secure (HTTPS), который передает обычный HTTP-трафик в зашифрованном канале TLS/SSL. И HTTP, и его защищенный вариант HTTPS являются протоколами «Stateless», то есть каждый запрос обрабатывается сервером как независимый от всех остальных. Однако некоторые веб-приложения должны помнить информацию о предыдущих запросах, например, чтобы отслеживать, выполнил ли пользователь необходимые шаги для процедуры оплаты. Для этих целей существуют файлы Cookie. Они являются наиболее распространенным механизмом для хранения информации о запросе клиента и реализации сеансов в Интернете. Грубо говоря, Cookie представляет собой пару «ключ-значение», которая записывается сервером в браузер клиента и каждый раз при попытке открыть страницу соответствующего сайта браузер пересылает этот фрагмент данных веб-серверу в составе HTTP-запроса.

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

На рис. 1 представлены компоненты любого веб-приложения, описанные выше.

Рисунок 1. Обобщенная архитектура веб-приложений

2.2. Характеристики Веб-ресурсов

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

Как показано на рис. 1, веб-приложение состоит из кода выполняемого, как на стороне сервера, так и на стороне клиента.

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

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

Клиентский код также может взаимодействовать с серверным кодом асинхронно, не мешая отображению существующей HTML-страницы через AJAX и динамически обновлять страницу. В настоящее время в целях содействия быстрой разработке приложений разрабатываются некоторые библиотеки и платформы программирования (например, Ruby on Rails и Django). Например, большинство платформ веб-разработки предоставляют функции управления сеансами, которые разработчики могут напрямую использовать для управления веб-сеансами. В статье [2] авторами были рассмотрены ключевые характеристики работы веб-ресурсов.

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

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

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

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

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

2.3. Выводы

Исходя из всего вышеописанного, опираясь на рассмотренную архитектуру и характеристики можно выявить несколько мест, где злоумышленник сможет провести свою атаку и навредить веб-ресурсу:

- анализ и защита входов в веб-ресурс (мониторинг вводимых пользователем данных);

- защита самого веб-приложения (анализ исходных кодов);

- защита выходов (анализ возвращаемых HTTP-ответов, анализ доступа

БД);

- анализ клиентской стороны (браузер).

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

3. Классификация защиты веб-ресурсов

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

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

Свойство «Предмет наблюдения» включает «Входы», «Приложение» и «Выходы», а свойство «Основание принятия решений» состоит из «Статистики», «Политики» и «Намерения».

Как следует из названия, первое свойство определяет, что анализирует защита. Например, защита может контролировать выход пользователя или приложения.

Второе свойство определяет, на чем основаны решения. Решения, основанные на «статистике» (обычно называемые обнаружением аномалий), построены на предположении, что атаки являются аномальными (редкими) событиями.

Решения на основе «политики» построены на предварительных знаниях или пожеланиях разработчика защиты и обычно используются в подходах, основанных на правилах.

В отличие от решений на основе «политики», решения, основанные на «намерениях», явно рассматривают намерения разработчика приложений (обычно с помощью анализа исходников приложения).

Таблица 1 — Классификация методов защиты веб-приложений

Основание принятия решений A. Статистика (аномалии — вероятностный взгляд) В. Политика (знания или пожелания разработчика защиты, основанные на правилах) С. Намерение (намерения разработчика приложений)

Предмет наблюдения 1) Входы (параметры HTTP GET / POST, файлы cookie, заголовок, URL-адреса — поведение пользователя) 2) Приложение (исходный код и подход «белый ящик») 3) Выходы (сгенерированная страница, активность базы данных/сети/файловой системы — поведение приложения)

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

Более сложным примером может быть A-1/3 или A-3 — типичные обнаружения аномалий методом «черного ящика».

3.1. Практики защиты и разработка веб-приложений

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

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

Усовершенствованная практика разработки направлена на создание безошибочных (или, по крайней мере, на минимизацию ошибок) приложений, что делает такие практики применимыми для новых веб-приложений.

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

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

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

Несмотря на то, что некоторые подходы к защите стремятся быть довольно универсальными, в целом защита зависит от используемого языка программирования и в основном ориентирована на наиболее популярные языки, такие как PHP, ASP или Java.

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

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

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

Таким образом, такие методы попадают в класс 2 или 1/3, в зависимости от того, используется ли подход «белый ящик» или «черный ящик».

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

3.2. Статистические (вероятностные) решения

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

ских решений на основе ранее собранных статистических данных, а не по заранее определенному списку правил.

Такая защита предполагает, что атака является аномальным событием, которое обычно не наблюдается при ежедневном использовании системы. Поэтому можно охарактеризовать «нормальное» поведение системы и выявить любые отклонения в дальнейшем. В статье [5] авторы описали решения, основанные на статистике, и рассмотрели этапы такой защиты.

Для реализации такого типа защиты требуются два общих шага:

1) Первый шаг, обычно известный как этап обучения, включает в себя определение того, каково нормальное поведение системы на самом деле.

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

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

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

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

Несмотря на использование различных математических абстракций, такие статистические подходы все еще имеют несколько общих проблем для решения. Авторы статьи [6] описали несколько проблем при реализации данного решения.

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

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

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

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

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

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

Защита не вызывает тревогу, поскольку наблюдаемый фактор (распределение символов) не отличается от обычного использования, тогда если учесть среднею длину запроса это также позволит обнаружить атаку (если обычная длина запроса значительно короче).

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

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

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

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

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

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

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

3.3. Решения на основе политик безопасности

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

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

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

Существенным недостатком таких подходов является проблема «угроз нулевого дня» — защита не в состоянии обнаружить незнакомые атаки.

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

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

- улучшение набора правил;

- расширение определений правил.

Однако, независимо от количества правил и уровня детализации, средства защиты, основанные на политике, концептуально ограничены их реактивным характером.

3.4. Решения, основанные на намерениях

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

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

лучшим источником намерений разработчика приложения является исходный код приложения (особенно если разработчик данного кода недоступен).

Подобно решениям, основанным на статистике, в решениях, основанных на намерениях, возможны два шага.

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

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

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

3.5. Анализ входа

Значительный класс атак, таких как SQL-инъекции или XSS-атаки, становится возможным из-за неправильной обработки предоставленных пользователем данных. Таким образом, появилась целая категория методов защиты, ориентированных на мониторинг вводимых пользователем данных.

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

Пользовательские входы (как правило, HTTP запросы GET/POST, файлы Cookie или заголовки) контролируются и анализируются в момент их поступления в защищаемое приложение. В зависимости от реализации, в случае обнаружения несоответствующих входных данных, либо удаляется вся транзакция, либо выполняется процедура восстановления (дезинфекция) для исправления входных данных. Типичными примерами такой «дезинфекции» являются специальные функции экранирования [8].

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

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

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

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

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

Кроме того, даже если обнаруженная ситуация является попыткой атаки, невозможно предсказать, удастся ли она (или какие действия следует предпринять для предотвращения атак, если таковые имеются) без глубокого понимания того, как организовано приложение.

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

3.6. Анализ приложения

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

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

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

Подход, основанный на анализе приложений, также может быть сфокусирован на выявлении различных расхождений и несоответствий для решения прикладных задач логического уровня. При таком подходе приложение рассматривается как набор входных параметров и потоков данных (назначение переменных) [9].

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

Если не все пути потока данных проверяют, является ли число, предоставленное пользователем положительным, пользователь может получить непреднамеренные скидки.

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

Затем выявленная проверка может быть автоматически применена для остальных путей потока данных, чтобы предотвратить атаки, основанные на неконтролируемом вводе пользователем. Кроме того, обработка различных проверок для одних и тех же данных не охватывается на различных путях.

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

3.7. Анализ выходов

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

Двумя наиболее распространенными способами взаимодействия, используемыми веб-приложениями, являются:

- HTTP-протокол (пары запроса / ответа);

- Доступ к базе данных.

Менее распространенное взаимодействие происходит через доступ к файловой системе и общий доступ к сети.

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

можно просматривать XSS атаки. Фокусировка на менее частых действиях (доступ к файлам и сети) может привести к тому, что большее количество атак останется необнаруженным.

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

3.8. Анализ стороны клиента

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

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

Методы защиты, ориентированные на серверную составляющую, сосредоточены только на защите веб-приложения с помощью соответствующей инфраструктуры поддержки, такой как сервер базы данных или файловая система. Типичными примерами серверных атак являются «SQL-инъекции», «Directory Traversal» или логические ошибки эксплуатации.

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

В клиент-ориентированные атаки можно включить два широких класса атак:

- Социальную инженерию;

- «Drive-by-Download» атаки.

Атаки, основанные на социальной инженерии, заставляют человека выполнять какие-либо действия вручную, в то время как «Drive-by-Download» атаки автоматически достигают той же цели за счет использования уязвимостей программного обеспечения.

Несмотря на то, что обновление программного обеспечения действительно может защитить от некоторых атак «Drive-by-Download», с атаками по классу социальной инженерии несколько сложнее бороться, используя чисто технические подходы, для этого часто требуется обучение пользователей.

3.9. Выводы

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

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

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

4. Существующие методы защиты веб-приложений

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

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

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

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

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

зируются внешние действия приложения (например, пары HTTP-запрос/ответ, действия доступа к базе данных и др.).

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

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

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

Аналогичное ограничение применимо к методам защиты на основе журналов событий (логов) [11]. Некоторые из менее динамичных методов защиты включают анализ лог-файлов приложений.

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

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

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

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

4.1. Методы «белого ящика»

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

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

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

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

Динамический анализ отслеживает исполнение кода приложения во время работы и может реагировать более активно (например, предотвращать выполнение некоторых ветвей кода). Анализ времени выполнения также позволяет анализатору иметь доступ к данным, предоставленным пользователем.

Такая гибкость обычно достигается путем расширения существующего интерпретатора языка программирования или стандартных библиотек.

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

Другая особенность анализа времени выполнения заключается в том, что наличие доступа к исходному коду позволяет создать модель предполагаемого поведения приложения. Такая модель может затем использоваться на этапе принятия решения о вторжении для проверки того, является ли выставленное поведение приложения ожидаемым.

Подходы «белого ящика» также могут быть сосредоточены на конкретных аспектах применения, таких как используемые API (вместо анализа самого приложения), приближенная структура веб-страниц.

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

4.2. Методы «черного ящика»

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

щее различие между подходами «черного ящика» заключается в предмете наблюдения. Просмотр веб-приложения в виде черного ящика означает, что подходы к защите имеют доступ только к входным и выходным данным приложения. В работе [14] рассмотрен данный подход и выделены его существенные недостатки.

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

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

Поэтому данные методы не будут рассмотрены в данном обзоре. Далее будут описаны актуальные методы защиты от существующих видов атак на веб-ресурсы.

4.3. Защита от SQL-инъекций

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

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

$mails = mysqli_query($con, "SELECT MailSubject FROM Mails WHERE MailDate > '".$_GET["date"]/"");

Оставив в стороне проблемы с аутентификацией, такой код может использоваться для извлечения списка сообщений электронной почты, полученных после указанной даты. Опасность этого кода заключается в, казалось бы, безвредном GET HTTP-запросе c параметром «date». Нежелательные последствия могут возникнуть, если посетитель веб-сайта подставит следующее значение для даты: 2000-01-01' OR 1=1

В этом случае будет создан следующий SQL-запрос:

SELECT MailSubject FROM Mails WHERE MailDate > '2000-01- 01' OR 1=1

Это приведет к включению в список всех объектов электронной почты. Более разрушительные результаты могут быть достигнуты с помощью другой структуры

для значения «date», например, включение символа «точка с запятой» для выполнения более чем одной команды SQL.

Хотя это пример небезопасного кода, аналогичные фрагменты кода часто встречаются по историческим причинам. Первоначально риски безопасности не были полностью поняты, и формирование SQL-запросов «на лету» путем объединения строк выглядело простым и естественным.

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

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

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

Таким образом, были предложены различные автоматизированные подходы.

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

Пользовательские входные данные передаются в такую функцию, которая фактически «очищает» их перед тем как сформировать окончательную строку SQL-запроса [16]. Популярным примером такого подхода является технология подготовленных заявлений (связанных переменных), доступная в PHP.

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

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

Если злоумышленник сможет предсказать (по крайней мере частично) форму сгенерированного SQL-запроса, атаки SQL-инъекции завершатся успешно. Такие

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

В последние годы было разработано много инструментов для обнаружения и предотвращения атак SQL-инъекций. Рассмотрим наиболее известные из них.

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

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

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

4.4. Защита от XSS-атак

Cross Site Scripting (XSS) атака — это злонамеренное программное воздействие на браузер пользователя в целях кражи данных или причинения иного вреда. Чтобы не путать понятие с таблицами стилей CSS (Cascading Style Sheets), договорились в сокращенном обозначении заменять первый символ буквой «X».

Атаки XSS стали возможными из-за того, что текущая разработка современных веб-приложений обычно связана с одновременным смешиванием нескольких языков. Это напоминает архитектуру Фон Неймана, где данные и код хранятся в одной и той же памяти. Например, HTML и JavaScript обычно возвращаются посетителю сайта в одном и том же потоке. В статье [17] авторы описали случаи возникновения XSS.

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

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

Атаки межсайтового скриптинга (XSS) обычно делятся на два типа:

- активные (хранимые);

- пассивные (отраженные).

Активные XSS-атаки являются постоянными, так как зловредно вводимые скрипты постоянно хранятся на стороне сервера, например, в базе данных в виде сообщения, отправленного на форум [18].

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

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

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

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

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

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

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

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

доверенными, поэтому некоторые исследователи предполагают, что атаки XSS можно рассматривать как проблему доверия, а не проблему несоответствия контекста.

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

Некоторые методы защиты от XSS не применяют никаких ограничений на ввод данных пользователем, вместо этого производится анализ обратного прокси-сервера для мониторинга исходящих HTTP-ответов [19].

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

4.5. Защита от встроенных в SVG атак

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

Учитывая, что изображения SVG могут содержать код JavaScript, может быть опасно принимать и вставлять SVG из неизвестных источников. Одной из возможных мер защиты может быть проверка SVG по сравнению с XML-схемой.

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

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

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

ограничение веб-браузеров от автоматического выполнения интерактивного контента.

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

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

4.6. Мониторинг входных данных

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

Существует три типа часто используемых входов в HTTP-протоколе — это параметры HTTP GET, параметры HTTP POST и HTTP заголовки. Интуиция таких подходов состоит в том, что некоторые характеристики различаются для входных данных, вызывающих атаки и входных данных, поступающих во время обычного ежедневного использования [20].

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

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

Ключевая проблема для подходов мониторинга пользовательского ввода заключается в выборе правильных характеристик для наблюдения. Часто используется несколько характеристик для повышения уровня обнаружения и уменьшения ложных срабатываний.

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

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

стика отличается для некоторых атак, разумно включить эту характеристику в список факторов, которые следует учитывать.

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

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

Необходимость анализа распределения входных символов объясняется тем фактом, что некоторые типы атак (например, SQL-инъекции) могут включать использование редких символов, которые обычно не встречаются при повседневном использовании.

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

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

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

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

4.7. Защита от загрязнения HTTP параметров

Такие средства защиты направлены на обход или обнаружение хотя бы некоторых типов атак с использованием параметров HTTP. Атака на заражение параметров HTTP возможна, поскольку спецификация протокола HTTP определяет только структуру входных параметров (предоставляемых пользователями), не налагая достаточных ограничений на фактические имена и значения параметров. В [21] авторы провели анализ HTTP запросов и привели примеры защиты параметров в них.

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

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

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

Таким образом, в зависимости от реализации некоторые параметры могут быть полностью потеряны и никогда не попадут в веб-приложение. Злоумышленники могут формировать HTTP-запросы, имеющие несколько параметров GET с тем же именем, что приводит к неоднозначностям на стороне сервера [22]. Некоторые серверные программы выбирают первое появление, в то время как другие выбирают последнее.

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

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

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

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

Таким образом, универсальное решение проблемы будет включать в себя разъяснение веб-стандартов (таких как процедуры обработки HTTP GET / POST). Однако это все равно потребует исправления существующих инструментов веб-разработки и среды исполнения.

4.8. Изоляция пользовательских входов

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

Хотя сосредоточение внимания на вводе данных пользователями выгодно с точки зрения раннего обнаружения, отсутствие разделения контекста между различными видами данных (например, пользовательский ввод и контент, генерируемый приложением) и кодом усложняет анализ вводимых данных пользователями.

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

Хотя в случае, если результатом является веб-страница, синтаксический анализ может позволить разделить различные структурные части строки, такие как JavaScript, HTML или CSS блоки. К сожалению, никакая структурная информация об источнике подстроки не хранится нигде в самой сгенерированной странице [23].

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

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

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

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

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

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

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

своей основе очень похожи на атаки SQL-инъекциями. Оба варианта возможны из-за несоответствия контекста.

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

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

<b> Welcome <img src-'..." /> ! </b>

Браузер будет интерпретировать данный фрагмент как код, который имеет четыре перехода контекста (табл. 2).

Таблица 2. Представление кода браузером

<b> HTML: разметка

Welcome 1. Текст: сообщение

<img src="..." /> 2. HTML: изображение

! 3. Текст: сообщение

</b> 4. HTML: разметка

Однако разработчик данного кода веб-страницы предполагает, что фрагмент будет иметь только два перехода контекста (табл. 3).

Таблица 3. Представление разработчиком

<b> HTML: разметка

Welcome 1. Текст: сообщение

<img src="..." /> Текст: имя пользователя

! Текст: сообщение

</b> 2. HTML: разметка

Первым предполагаемым переходом является изменение контекста с HTML разметки на статический текст, а вторым — контекстный переход обратно к HTML разметке, после окончания статического текста. Однако, если злоумышленнику на веб-странице удается внедрить <img src—'..." /> вместо законного имени пользователя, появляются два непредвиденных перехода.

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

Например, обнаружение XSS-атак может выполняться путем анализа HTTP-ответов, но для атак SQL-инъекциями необходимы другие источники, такие как анализ PHP кода или мониторинг запросов к базе данных во время работы [24].

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

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

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

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

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

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

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

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

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

Таким образом, в отличие от вероятностных подходов, точное решение возможно, если учесть намерение разработчика (полученное из имеющегося исходного кода).

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

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

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

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

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

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

- охватить максимально широкий класс уязвимостей;

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

Литература

[1] Bugliesi M., Calzavara S., Focardi R. Formal methods for Web security // Journal of Logical and Algebraic Methods in Programming. 2017. Vol. 87. P. 110-126.

[2] Deepa G., Thilagam P. S. Securing Web applications from injection and logic vulnerabilities: Approaches and challenges // Information and Software Technology. 2016. Vol. 74. P. 160180.

[3] Prokhorenko V., Choo K.-K. R., Ashman H. Web application protection techniques: A taxonomy // Journal of Network and Computer Applications. 2016. Vol. 60. P. 95-112.

[4] Li X., Xue Y. A survey on server-side approaches to securing web applications // ACM Computing Surveys (CSUR). 2014. Vol. 46. No. 4. Art. 54.

[5] Bherde G. P., PundM. A. Recent attack prevention techniques in Web service applications // International Conference on Automatic Control and Dynamic Optimization Techniques 2016 (ICACDOT-16). — 2017. P. 1174-1180.

[6] Uwagbole S. O., Buchanan W. J., Fan L. Applied Machine Learning predictive analytics to SQL Injection Attack detection and prevention // IFIP/IEEE Symposium on Integrated Network and Service Management 2017 (IM). — 2017. P. 1087-1090.

[7] Huang H.-C., Zhang Z.-K., Cheng H.-W., Shieh S. W. Web Application Security: Threats, Countermeasures, and Pitfalls // Journal Computer. 2017. Vol. 50. No. 6. P. 81-85.

[8] Xiao X., Yan R., Ye R., Li Q., Peng S., Jiang Y. Detection and Prevention of Code Injection Attacks on HTML5-Based Apps // Third International Conference on Advanced Cloud and Big Data 2015. — 2016. P. 254-261.

[9] Osman A. M., Dafa-Allah A., Elhang A. A. M. Proposed security model for web based applications and services // International Conference on Communication, Control, Computing and Electronics Engineering 2017 (ICCCCEE), — 2017. P. 1-6.

[10] Gupta M. K., Govil M. C., Singh G. Predicting Cross-Site Scripting (XSS) security vulnerabilities in web applications // 12th International Joint Conference on Computer Science and Software Engineering 2015 (JCSSE). — 2015. P. 162-167.

[11] Moh M., Pininti S., Doddapaneni S., Moh T.-S. Detecting Web Attacks Using Multi-stage Log Analysis // IEEE 6th International Conference on Advanced Computing 2016 (IACC). — 2016. P. 733-738.

[12] Rexha B., Halili A., Rrmoku K., Imeraj D. Impact of secure programming on web application vulnerabilities // International Conference on Computer Graphics, Vision and Information Security 2015 IEEE (CGVIS). — 2016. P. 61-66.

[13] Medeiros I., Neves N. F., Correia M. Automatic detection and correction of Web application vulnerabilities using data mining to predict false positives // WWW 2014 — Proceedings of the 23rd International Conference on World Wide Web. — 2014. P. 63-74.

[14] Salas M. I. P., Martins E. A Black-Box Approach to Detect Vulnerabilities in Web Services Using Penetration Testing // IEEE Latin America Transactions. 2015. Vol. 13. No. 3. P. 707712.

[15] Khanna S., Verma A. K. Classification of SQL injection attacks using fuzzy tainting // Advances in Intelligent Systems and Computing. 2018. Vol. 518. P. 463-469.

[16] Backes M., Rieck K., Skoruppa M., Stock B., Yamaguchi F. Efficient and Flexible Discovery of PHP Application Vulnerabilities // IEEE European Symposium on Security and Privacy 2017 (EuroS&P). — 2017. P. 334-349.

[17] Prokhorenko V., Choo K.-K. R., Ashman H. Context-oriented web application protection model // Applied Mathematics and Computation. 2016. Vol. 285. P. 59-78.

[18] Sonewar P. A., Thosar S. D. Detection of SQL injection and XSS attacks in three tier web applications // International Conference on Computing Communication Control and automation 2016 (ICCUBEA). — 2017. P. 1-4.

[19] Pandiaraja P., Manikandan J. Web proxy based detection and protection mechanisms against client based HTTP attacks // International Conference on Circuits, Power and Computing Technologies 2015 (ICCPCT-2015). — 2015. P. 1-6.

[20] Kshirsagar D., Kumar S. HTTP flood attack detection using ontology // Proceedings of the International Conference on Advances in Information Communication Technology & Computing 2016 (AICTC '16). — 2016. Art. 15.

[21] Zolotukhin M., Hamalainen T., Kokkonen T., Siltanen J. Analysis of HTTP requests for anomaly detection of web attacks // IEEE 12th International Conference on Dependable, Au-tonomic and Secure Computing 2014. — 2014. P. 406-411.

[22] Szabo R., Hudec L. Identification of vulnerable parts of web applications based on anomaly detection in HTTP // Proceedings of the 14th International Conference on Computer Systems and Technologies (CompSysTech '13). — 2013. P. 209-215.

[23] Sivakorn S., Keromytis A. D., Polakis J. That's the way the Cookie crumbles: Evaluating HTTPS enforcing mechanisms // Proceedings of the 2016 ACM on Workshop on Privacy in the Electronic Society (WPES '16). — 2016. P. 71-81.

[24] Al-Khurafi O. B., Al-Ahmad M. A. Survey of Web Application Vulnerability Attacks // 4th International Conference on Advanced Computer Science Applications and Technologies 2015 (ACSAT). — 2016. P. 154-158.

[25] Medeiros I., Neves N., Correia M. Detecting and Removing Web Application Vulnerabilities with Static Analysis and Data Mining // IEEE Transactions on Reliability. 2016. Vol. 65. No. 1. P. 54-69.

Автор:

Сергей Александрович Лесько — кандидат технических наук, доцент кафедры управления и моделирования систем, МИРЭА — Российский технологический университет

Models and methods of protecting web resources: a systematic review

S. Lesko

MIREA — Russian Technological University, 78 Vernadsky Avenue, Moscow 119454 e-mail: lesko@mirea.ru

Abstract. The presented review based on description of existing models and methods for protecting web resources and the possibility of creating automated vulnerability detection tools. From a bird view, it can be noted that there are some similarities between some types attacks which can looks different. For example, the XSS attacks are basically very similar to SQL injection attacks. The root of the problem is the lack of separation of data and (sometimes several) code streams. However, despite the root similarities between XSS attacks and SQL injections, it can be difficult to apply the same protection against many types of attacks due to technical difficulties. For example, XSS attacks can be detected by analyzing HTTP responses, but for SQL injection attacks, we need analyze other sources, such as analyzing PHP code or do some database queries monitoring at runtime. Given some contextual similarities in these types of attacks, we can say that developing a unified approach for defend against them would be very useful. First, that kind context-based attacks are possible due to the lack of user data isolation. Based on a review of the articles, we can conclude that the further development of such methods (vulnerability detection and web application protection) can be further developed with hybridization of various methods. This will covered the widest possible class of vulnerabilities and controls the completeness of their detections, so, based on the results of automatic analysis, we could guarantee that there are no vulnerabilities of the specified classes. Keywords: models and methods of web resources protecting, security policies, inputs and outputs analysis, client-side analysis, HTTP parameters pollution.

References

[1] Bugliesi M., Calzavara S., Focardi R. (2017) J. ofLog. andAlgeb. Meth. in Program., 87: 110-126.

[2] Deepa G., Thilagam P. S. (2016) Securing Information and Software Technology, 74:160-180.

[3] Prokhorenko V., Choo K.-K. R., Ashman H. (2016) J. ofNetwork and Computer Appl., 60:95-112.

[4] Li X., Xue Y. (2014) ACM Computing Surveys, 46(4):54.

[5] Bherde G. P., Pund M. A. (2017) Recent attack prevention techniques in Web service applications. In International Conference on Automatic Control and Dynamic Optimization Techniques 2016 (ICACDOT-16), pp. 1174-1180.

[6] Uwagbole S. O., Buchanan W. J., Fan L. (2017) Applied Machine Learning predictive analytics to SQL Injection Attack detection and prevention. In IFIP/IEEE Symposium on Integrated Network and Service Management 2017 (M), pp. 1087-1090.

[7] HuangH.-C., Zhang Z.-K., ChengH.-W., Shieh S. W. (2017) Journal Computer, 50(6):81-85.

[8] XiaoX., Yan R., ...& Jiang Y. (2016) Detection and Prevention of Code Injection Attacks on HTML5-Based Apps. In Third International Conference on Advanced Cloud and Big Data 2015, pp. 254-261.

[9] Osman A. M., Dafa-Allah A., Elhang, A. A. M. (2017) Proposed security model for web based applications and services. International Conference on Communication, Control, Computing and Electronics Engineering 2017 (ICCCCEE), pp. 1-6.

[10] Gupta M. K., Govil M. C., Singh G. (2015) Predicting Cross-Site Scripting (XSS) security vulnerabilities in web applications. In 12th International Joint Conference on Computer Science and Software Engineering 2015 (JCSSE), pp. 162-167.

[11] Moh M., Pininti S., Doddapaneni S., Moh T.-S. (2016) Detecting Web Attacks Using Multi-stage Log Analysis. In IEEE 6th International Conference on Advanced Computing 2016 (IACC), pp. 733-738.

[12] Rexha B., Halili A., Rrmoku K., Imeraj D. (2016) Impact of secure programming on web application vulnerabilities. In 2015 IEEE Int. Conf. on Comp. Graphics, Vision and Inform. Security, pp. 61-66.

[13] Medeiros I., Neves N. F., Correia M. (2014) Automatic detection and correction of Web application vulnerabilities using data mining to predict false positives. In WWW 2014 — Proceedings of the 23rd International Conference on World Wide Web, pp. 63-74.

[14] Salas M. I. P., Martins E. (2015) IEEE Latin America Transactions, 13(3):707-712.

[15] Khanna S., Verma A.K. (2018) Adv. in Intelligent Systems and Computing, 518:463-469.

[16] Backes M., Rieck K., ... & Yamaguchi F. (2017) Efficient and Flexible Discovery of PHP Application Vulnerabilities. In IEEE European Symposium on Security and Privacy 2017 (EuroS&P), pp. 334-349.

[17] Prokhorenko V., Choo K.-K. R., Ashman H. (2016) Appl. Mathematics and Computation, 285:59-78.

[18] Sonewar P. A., Thosar S. D. (2017) Detection of SQL injection and XSS attacks in three tier web applications. In International Conference on Computing Communication Control and automation 2016 (ICCUBEA), pp. 1-4.

[19] Pandiaraja P., Manikandan J. (2015) Web proxy based detection and protection mechanisms against client based HTTP attacks. In International Conference on Circuits, Power and Computing Technologies 2015 (ICCPCT-2015), pp. 1-6.

[20] Kshirsagar D., Kumar S. (2016) HTTP flood attack detection using ontology. In Proceedings of the International Conference on Advances in Information Communication Technology & Computing 2016 (AICTC '16), art. no. 15.

[21] Zolotukhin M., Hamalainen T., Kokkonen T., Siltanen J. (2014) Analysis of HTTP requests for anomaly detection of web attacks. In IEEE 12th International Conference on Dependable, Autonomic and Secure Computing 2014, pp. 406-411.

[22] Szabo R., Hudec L. (2013) Identification of vulnerable parts of web applications based on anomaly detection in HTTP. In Proceedings of the 14th International Conference on Computer Systems and Technologies (CompSysTech '13), pp. 209-215.

[23] Sivakorn S., Keromytis A. D., Polakis J. (2016) That's the way the Cookie crumbles: Evaluating HTTPS enforcing mechanisms. In Proceedings of the 2016 ACM on Workshop on Privacy in the Electronic Society (WPES '16), pp. 71-81.

[24] Al-Khurafi O. B., Al-Ahmad M.A. (2016) Survey of Web Application Vulnerability Attacks. 4th International Conference on Advanced Computer Science Applications and Technologies 2015 (ACSAT), pp. 154-158.

[25] Medeiros I., Neves N., CorreiaM. (2016) IEEE Transactions on Reliability, 65(1):54-69.