Файрвол веб-приложений

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Файрвол веб-приложений (англ. Web application firewall, WAF) — совокупность мониторов и фильтров, предназначенных для обнаружения и блокирования сетевых атак на веб-приложение. WAF относятся к прикладному уровню модели OSI[1].

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

Описание[править | править код]

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

В WAF могут поддерживаться любые модели безопасности: позитивные, негативные или их комбинации. К современным WAF предъявляются требования, описанные в PCI DSS. Так же они инспектируют запросы и ответы HTTP/HTTPS протокола передачи данных в соответствии с политикой безопасности[3]. Кроме того, открытый проект OWASP собирает данные о компрометациях со всего мира и формирует рейтинг векторов атак на веб-приложения — OWASP Top Ten[4]. WAF проектируются так, чтобы успешно реагировать на угрозы описанные в этом рейтинге[3].

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

Векторы атак[править | править код]

Инъекции[править | править код]

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

Использование уязвимостей хранения сессий[править | править код]

Для различения пользователей при авторизации пользователя на сайте ему ставится сессионный куки или выдаётся токен авторизации, который браузер сохраняет и каждый раз отправляет на сервер, для подтверждения того, что это нужный пользователь. Этот ключ может быть получен злоумышленником и использован для доступа к аккаунту[9]. Для защиты вместе с ключом проверяется сопутствующая информация такая как, IP адрес, браузер. Так же ключу сессии ставят относительно недолгий срок жизни[10].

XSS (Межсайтовое выполнение сценариев)[править | править код]

Этот вид атак заключается в том, что злоумышленник передаёт Java-Script или Html код в браузер пользователя, где этот код исполняется[7]. Таким образом злоумышленник может получить куки или данные вводимые на форме заражённой страницы. Для защиты экранируются входные и выходные данные. Используются регулярные выражения для валидации полей[11].

Незащищённость конфиденциальных данных[править | править код]

Этот вид атак предназначен для кражи конфиденциальных данных. Чаще всего это происходит в момент их передачи от клиента на сервер по незащищённому протоколу HTTP или FTP. На пути к серверу, на каком-то узле, получив к нему доступ, злоумышленник может прочитать открытый, незащищённый запрос с конфиденциальной информацией пользователя[12]. Для передачи подобной информации используют защищённые протоколы передачи HTTPS, TLS. Помимо этого, если есть необходимость хранить такие данные, то хранятся они в зашифрованном виде[12].

Использование уязвимостей контроля доступа[править | править код]

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

Например, если злоумышленник имеет id равный 1 и может видеть список своих сообщений по ссылке

mysite.com/messages?id=1

то при недостаточной проверке прав, заменив значение id на 2 

mysite.com/messages?id=2

сервер выдаст сообщения пользователя с id = 2. В качестве защиты для проверки доступа используют белые списки. Хотя некоторые WAF берут на себя подобные функции проверки, но преимущественно, эти действия выполняются на сервере[14].

Использование внешних XML-сущностей[править | править код]

В отчёте OWASP за 2017 год в топ возможных рисков для веб-приложений попал такой вектор атак как XML External Entities (XXE)[15]. Возможность таких атак возникает, когда приложение предоставляет возможность пользователю для передачи данных использовать документы XML, содержимое которых анализируется плохо настроенным парсером. В результате злоумышленник может передать в XML ссылку на внешнюю сущность, что может привести к потере данных, либо к другим нежелательным воздействиям на сервер[16][17]. Для защиты используется тщательно настроенный сериализатор XML либо он заменяется на другой, например, JSON. Или отключается поддержка внешних сущностей XML[18].

Следует отметить, что некоторым стандартным атакам можно противостоять, включая соответствующие заголовки и флаги, встроенные во все современные браузеры. Например, заголовок X-XSS-Protection или флаг HTTPonly у заголовка Set-Cookie[19][20].

Методы защиты[править | править код]

Сигнатурный анализ[править | править код]

WAF активно используют сигнатурный анализ для фильтрации трафика. Сигнатурный метод в своей реализации использует словарь вредоносного трафика для сравнения[21]. Если в пришедшем трафике нашлась часть запроса(сигнатура), которая соответствует вредоносному трафику, то WAF блокируют этот запрос. Пример сигнатур[22].

Репутационный фильтр IP адресов[править | править код]

Метод основан на белых и чёрных списках IP адресов и доменов. Ссылаясь на эти списки, WAF оценивают входящие запросы[2].

Некоторые популярные блок-листы:

Поведенческий анализ[править | править код]

Поведенческий анализ строится на машинном обучении. Это позволяет обнаружить аномалии в поведении на глубоких уровнях понимания. Такой механизм может обучаться как с учителем так и без учителя на идентификаторах доступа. Входящими параметрами могут служить идентификаторы доступа такие как HTTP-параметры, идентификатор ресурса (URL, URN), идентификатор сессии[1]. Таким образом выделяется эталонная математическая модель допустимых идентификаторов доступа. При несовпадении с этой моделью очередной запрос будет заблокирован[5]. Это позволяет отражать как известные атаки, так и атаки нулевого дня[2].

Дополнительные возможности[править | править код]

Защита от DoS-атак[править | править код]

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

Сканеры уязвимостей[править | править код]

WAF в комплекте могут иметь собственный сканер уязвимостей. Сканер обращает внимание разработчиков приложения на недочёты, которые впоследствии могут быть исправлены, либо ответственность за них может быть делегирована WAF. В ходе такого анализа сканер может генерировать запросы с конкретными значениями параметров, которые позволят эксплуатировать найденную уязвимость. Зная слабые места веб-приложения WAF генерируют виртуальные патчи, которые закрывают такие места[23].

Виды поставок[править | править код]

WAF предоставляют несколько видов поставок.

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

В любом из этих случаев WAF могут быть развёрнуты в одном из вариантов: прозрачный мост, прозрачный или обратный прокси сервер[24].

Рынок[править | править код]

С увеличением количества веб-приложений в сети Интернет растёт потребность в их квалифицированной защите[25]. Это является фактором развития компаний в данном направлении. Многие компании участвуют в развитии отрасли. Проводят открытую аналитику рынка, технологий и угроз. Поскольку за время развития веб-защиты выработаны принципы и стандарты безопасности, то WAF продукты от различных компаний схожи по своей функциональности и отличаются лишь графической оболочкой[3].

Наиболее популярные решения:

WAF с открытым исходным кодом:

Примечания[править | править код]

  1. 1 2 3 Системы защиты веб-приложений Web Application Firewall (WAF). Anti-Malware.ru. Дата обращения 11 декабря 2019.
  2. 1 2 3 Alexander Antipov. Чем защищают сайты, или Зачем нужен WAF?. www.securitylab.ru. Дата обращения 11 декабря 2019.
  3. 1 2 3 Обзор рынка защиты веб-приложений (WAF) в России и в мире. Anti-Malware.ru (12 августа 2015). Дата обращения 11 декабря 2019.
  4. Category:OWASP Top Ten Project - OWASP (недоступная ссылка). www.owasp.org. Дата обращения 11 декабря 2019. Архивировано 1 декабря 2019 года.
  5. 1 2 3 Коробочная безопасность веб-приложений. Внутренности Web Application Firewall. Anti-Malware.ru (5 октября 2015). Дата обращения 11 декабря 2019.
  6. OWASP Top10 2017 // OWASP.
  7. 1 2 Michael Cross. Developer’s Guide to Web Application Security. — ISBN 1-59749-061-X.
  8. PHP: SQL-инъекции - Manual. www.php.net. Дата обращения 12 декабря 2019.
  9. Katy Anton, Jim Manico, Jim Bird. 10 Critical Security Areas That Software Developers Must Be Aware Of // https://www.owasp.org : руководство по защите веб-приложений. — 2018.
  10. What is and how to prevent Broken Authentication and Session Management | OWASP Top 10 (A2) (англ.). hdivsecurity.com. Дата обращения 11 декабря 2019.
  11. Cross Site Scripting Prevention · OWASP Cheat Sheet Series. cheatsheetseries.owasp.org. Дата обращения 12 декабря 2019.
  12. 1 2 Top 10-2017 A3-Sensitive Data Exposure - OWASP. www.owasp.org. Дата обращения 11 декабря 2019.
  13. Top 10-2017 A5-Broken Access Control - OWASP. www.owasp.org. Дата обращения 13 декабря 2019.
  14. Category:OWASP Best Practices: Use of Web Application Firewalls/Version 1.0.5 - OWASP. www.owasp.org. Дата обращения 11 декабря 2019.
  15. Top 10-2017 Top 10 - OWASP. www.owasp.org. Дата обращения 11 декабря 2019.
  16. Carrie Roberts. A Hands-on XML External Entity Vulnerability Training Module. — 2013.
  17. XML External Entity (XXE) Processing - OWASP. www.owasp.org. Дата обращения 11 декабря 2019.
  18. XXE (Xml eXternal Entity) — Национальная библиотека им. Н. Э. Баумана. ru.bmstu.wiki. Дата обращения 11 декабря 2019.
  19. Security Headers - OWASP. www.owasp.org. Дата обращения 15 декабря 2019.
  20. HttpOnly - OWASP. www.owasp.org. Дата обращения 15 декабря 2019.
  21. С. И. Макаренко. Информационная безопасность: учебное пособие для студентов вузов.
  22. Nemesida WAF rules.bin. rlinfo.nemesida-security.com. Дата обращения 12 декабря 2019.
  23. Виртуальный патчинг | Nemesida WAF (14 сентября 2017). Дата обращения 11 декабря 2019.
  24. Сравнение фаерволов для защиты веб-сайтов (Web Application Firewall — WAF). Anti-Malware.ru (3 октября 2017). Дата обращения 11 декабря 2019.
  25. Digital 2019: Global Internet Use Accelerates (англ.). We Are Social (30 January 2019). Дата обращения 12 декабря 2019.