Защита сайта от хакерских атак

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

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

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

Уязвимости нулевого дня

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

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

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

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

В качестве примера можно привести хронологию атаки Struts2: CVE-2013-2251 Struts2 Prefixed Parameters OGNL Injection Vulnerability — c момента появления «боевого» эксплойта прошло несколько дней, прежде чем многие компании смогли накатить патч.

Тем не менее, при использовании защитных средств можно было выявить запрос вида:
http://host/struts2-blank/example/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}
для блокирования атаки, т.к. он явно не является легитимным в контексте пользовательских действий.

«Классические» атаки

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

• SQL Injection — sql инъекции;
• Remote Code Execution (RCE) — удаленное выполнение кода;
• Cross Site Scripting (XSS) — межсайтовый скриптинг;
• Cross Site Request Forgery (CSRF) — межстайтовая подделка запросов;
• Remote File Inclusion (RFI) — удалённый инклуд;
• Local File Inclusion (LFI) — локальный инклуд;
• Auth Bypass — обход авторизации;
• Insecure Direct Object Reference — небезопасные прямые ссылки на объекты;
• Bruteforce — подбор паролей.

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

Защита на прикладном уровне

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

Протокол прикладного уровня — протокол верхнего (7-го) уровня сетевой модели OSI, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Защита сайта на прикладном уровне является наиболее надежной. Уязвимости, эксплуатируемые злоумышленниками, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью классических систем обнаружения вторжений. Также этот уровень является самым доступным извне. Возникает необходимость понимать группы протоколов и зависимостей, свойственных для веб-приложений, которые строятся над прикладными протоколами http/https.

Основной принцип защиты сайта на прикладном уровне — верификация и фильтрация данных запросов, передаваемых методами GET, POST и т.д. Подмена или модификация запроса — это базовая основа практически всех способов взлома и атак на сайты.

Цели атак

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

• Каждый третий сайт был взломан или подвергался атакам хакеров;
• 80% сайтов взламываются в ходе нецелевых атак с использованием популярных сканеров или утилит;
• Около 60% взломанных сайтов были заражены и заблокированы поисковыми системами.

Для сайтов, оперирующих платежными данными, обрабатывающих онлайн-транзакции существует специализированные требования соответствия стандарту PCI DSS. Payment Card Industry Data Security Standard (PCI DSS) — стандарт безопасности данных индустрии платёжных карт, разработанный Советом по стандартам безопасности индустрии платежных карт (Payment Card Industry Security Standards Council, PCI SSC), учреждённым международными платёжными системами Visa, MasterCard, American Express, JCB и Discover.

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

To gain a better understanding of the Requirement 6.6, we should refer to PCI DSS 3.1 standard which says that public-facing web applications shall “address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.”
What is important here is the “on an ongoing basis” condition, which makes it very clear that web security is a permanent process and highlights the importance of continuous web security.
PCI DSS proposes two ways to achieve this requirement:
“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.”
“Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.”

Пункт 6.6 носит обязательный характер, если веб-приложение входит в CDE (Cardholder Data Environment).

Обеспечение защиты сайта

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

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

Как это работает

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



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

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

Эффективность применения Web Application Firewall складывается из нескольких факторов:

• Простая интеграция в инфраструктуру;
• Гибкая система адаптации с веб-приложением;
• Блокирование угроз OWASP Top 10;
• Анализ и блокирование аномалий протокола или данных;
• Обнаружение и блокирование подделки идентификаторов сессий;
• Обнаружение и блокирование подбора паролей;
• Инспекция ответов сервера на наличие критичных данных;
• Динамическое обновление сигнатур атак;
• Низкое количество ложных срабатываний;
• Самозащита WAF;
• Удобный сервис информирования об атаках;
• Статистика и регламентная отчетность.