Защита веб-приложения: практические кейсы

image

Безопасность веб-приложений находится в первой десятке трендов и угроз информационной безопасности уже свыше 10 лет. Действительно, современные бизнес-процессы и повседневная жизнь — все больше и больше зависит от использования веб-приложений, в разнообразнейших аспектах: от сложных инфраструктурных систем до IoT устройств. Тем не менее специализированных средств защиты веб-приложений довольно мало, по большей части эту задачу возлагают (или надеются что она будет решена) на разработчиков. Это и использование различных фреймворков, средств санации, очистки данных, нормализации и многого другого. Тем не менее, даже с использованием этих средств безопаснее веб не стал, более того, в все уязвимости «классического веба» практически в неизменном виде мигрировали в мобильную разработку. В этой статье будет рассказано не как не допустить уязвимость, а как защитить веб-приложение от ее эксплуатации с использованием Web Applicatin Firewall.

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

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

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

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

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

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

Практика и статистика


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

Давайте пройдемся по блогу «информационная безопасность» и посмотрим что было «горячего» за последнее время:

Кейс: 3 апреля: 0day в банковском ПО для геолокации (топик удален)
Тип уязвимости: SQL injection, RCE, Auth Bypass.
Описание: слепая инъекция на форме входа в службу геолокации банка. Сервис критичный, доступен в сети интернет.
Риски: бизнес процессы, безопасность, кража, репутация.

Кейс: 24 марта: Взлом сайта доставки пиццы, взлом mobidel.ru
Тип уязвимости: Insecure Direct Object References, хранимая XSS, захват сессии
Описание: отсутствие каких-либо проверок, классические клиент-сайд атаки.
Риски: бизнес процессы, безопасность, кража, репутация.

Кейс: 22 марта: Немного о приватности реальных Git-репозиториев
Тип уязвимости: Insecure Direct Object References, раскрытие информации
Описание: прямой доступ к критичным объектам.
Риски: получения информации о приложения для развития атаки.

Кейс: 12 марта: Надёжная авторизация для веб-сервиса за один вечер
Тип уязвимости: SQL injection
Описание: типичный разработчик, фигак-фигак и в продакшн.
Риски: security through obscurity.

Кейс: 6 марта: Как взламывают телеком-провайдеров: разбор реальной атаки
Тип уязвимости: SQL injection
Описание: взлом периметра через веб, проникновение в сеть.
Риски: бизнес процессы, безопасность, кража, репутация.


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

Защита


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

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

  • моментально обрабатывать трафик;
  • блокировать нелегитимные запросы;
  • выявлять бот-активность;
  • уметь работать с любым протоколом http/https;
  • не зависеть от платформы веб-приложения;
  • уметь выявлять брутфорс-атаки, краулинг и т.д.
  • уметь работать с вебсокетами и т.д.;
  • минимизировать false детекты;
  • блокировать DoS (L7);
  • выявлять и блокировать новые атаки, в т.ч. с помощью машинного обучения;
  • содержать актуальную и пополняемую базу сигнатур атак;
  • содержать актуальную и пополняемую базу IP-reputation;
  • применять virtual patching.

Nemesida WAF — это межсетевой экран прикладного уровня (Web Aplication Firewall), позволяющий эффективно защищать сайты от хакерских атак даже в случае наличия на сайте уязвимости «нулевого дня».

Продолжение


В следующей части я разберу методы противодействия защитным средствам со стороны злоумышленников: популярные методы обхода современных Web Application Firewall, атаки на сами сервисы защиты и т.д.

Комментарии (0)

© Habrahabr.ru