Обеспечение безопасности веб-приложений: методы анализа и противодействия атакам. Часть 2

Защита веб-приложений: от анализа до противодействия атакам. Часть 2
Время на прочтение: 8 минут

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

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

Сегодня применим полученные данные на практике и расскажем:

  • как минимизировать риски,
  • какие решения помогут снизить вероятность успешных DDoS-атак,
  • когда лучше подключать специализированные средства защиты, такие как Web Application Firewall (WAF),
  • чем может помочь сервис-провайдер.

Шаг 3. Купируем риски

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

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

Недоступность приложения

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

Первый шаг — провести тестирование на устойчивость к DDoS. Речь об имитации такой атаки. В первую очередь стоит протестировать устойчивость к DDoS на уровне L7 (уровень веб-приложения). После чего можно запустить сценарий на инфраструктурном уровне L4. Провести обе проверки можно с помощью MHDDoS, PyDDoS и множества других инструментов с открытым кодом. Все они позволяют запускать разные сценарии атак. Также есть сервисы, которые проводят тестирование под ключ.

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

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

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

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

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

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

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

Также всегда можно воспользоваться платным вариантом. И здесь есть два пути. Первый — приобрести специализированное оборудование для защиты от DDoS-атак. Но здесь важно помнить, что у CAPEX есть ряд неудобств: сложная настройка, трудности с закупкой и ограничения по пропускной способности. Всегда есть риск приобрести оборудование с защитой трафика, например до 10 Гбит/с, но на практике столкнуться с более мощными атаками.

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

Аудит ИБ
Найдем слабые места в информационной безопасности вашей корпоративной инфраструктуры

Кража контента (web scraping)

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

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

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

Кроме того, для защиты от кражи данных можно использовать бесплатные инструменты. В их числе решения, которые встраиваются в код приложения или интегрируются с веб-сервером. Пример — ngnix-ultimate-bad-bot-blocker. Есть и коммерческие варианты: Qrator, DDoSGuard, CloudFlare и другие.

Компрометация приложений

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

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

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

  • Настройка правил в файрволе. В идеале лучше сразу подключить межсетевой экран со встроенными модулями IPS и IDS для обнаружения и предотвращения вторжений (NGFW).
  • Разграничение доступа. Всегда важно знать, какие учетные записи используются для работы сотрудников с веб-приложением. Причем логины-пароли администраторов лучше хранить отдельно от клиентских. Также для защиты учетных данных от взлома рекомендуем подключить многофакторную аутентификацию.
  • Ограничение доступа к админским консолям. Желательно не опубликовывать админские консоли и интерфейсы в интернете, давать доступ к ним только из внутренней сети. А если администраторы подключаются удаленно, то стоит подумать о VPN. Такие данные на ресурсах внешнего периметра — идеальный кейс для хакинга.

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

Если этих действий оказалось недостаточно, то выход из ситуации очевиден: стоит подключить превентивную защиту. И лучшее решение здесь —- это Web Application Firewall (WAF), или межсетевой экран для веб-приложений.

Сервис защиты веб-приложений (WAF)
Три недели бесплатного тест-драйва

Подключаем WAF

Такой файрвол интегрируется с веб-ресурсом и анализирует входящие запросы по критериям OWASP-10, готовым правилам вендоров и другим параметрам. В результате зловредный и паразитный трафик фильтруется на входе в веб-приложение. При этом почти во всех WAF можно прописывать свои правила. Благодаря этому можно закрывать опасные уязвимости, которые не удается закрыть обновлением или доработкой кода.

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

Как и в случае с множеством других средств защиты, есть opensource и коммерческие варианты. Среди бесплатных популярны ModSecurity и Coraza WAF от OWASP, а также Nemesida WAF Community Edition. Примеры коммерческих файрволов: Cloudflare, PT Application Firewall.

Обращаемся к сервис-провайдеру

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

Сервисная модель позволяет не только эффективно обезопасить инфраструктуру от рисков, но и получить дополнительные плюсы. Разберем на примере сервиса защиты веб-приложений от НУБЕС (Nubes).

Клиенты получают защиту от таких рисков, как:

  • остановка работы сайта или приложений, в том числе из-за DDoS-атак на уровне L7 и инцидентов со злоупотреблением логикой работы приложения (web form abuse),
  • несанкционированный доступ к учетным данным, который хакеры могут получить в результате XSS-инъекций, перебора и подбора паролей (brute force, credential stuffing),
  • проникновение злоумышленников в инфраструктуру компании — как с помощью удаленного запуска кода, так и подделки запросов со стороны сервера (SSRF),
  • утечки данных, которые возможны при атаках с внедрением SQL-кода, а также с получением доступа к исходному коду приложений (Git, SVN) и их объектам (IDOR).

Чтобы обезопасить веб-приложения клиента, сервис-провайдер регулярно проводит сканирование на уязвимости и помогает своевременно закрывать их. При этом трафик фильтруется на уровне DDoS L7 еще до поступления в облачный WAF (PT Cloud Application Firewall).

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

Новые статьи и анонсы вебинаров в нашем Телеграм-канале