Безопасность веб-приложений: от уязвимостей до мониторинга

Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.

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

Распространенные уязвимости

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

Инъекции

Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.

http://example.com/?id=1' union select 1,2,version(),4
http://example.com/search.php?q=;cat+/etc/passwd

XSS

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

http://example.com/?search=<script>alert('xss')</script>

LFI/RFI

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

http://example.com/?search=/../../../../../../etc/passwd

Атаки через JSON и XML

Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.

JSON

JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.

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

POST /index.php?rest_route=%2Fwp%2Fv2%2Fposts%2F12&_locale=user HTTP/1.1
Host: wordpress.example.com
...
%Другие заголовки%
...

{"id":12,"title":"test title","content":"test body","status":"publish"}

JSON Injection

Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:

• Сервер хранит пользовательские данные в виде строки JSON, включая тип учетной записи;
• Имя пользователя и пароль берутся непосредственно из пользовательского ввода без очистки;
• Строка JSON формируется с помощью простой конкатенации:
  $json_string = '{"account":"user","user":"'.$_GET['user'].'","pass":"'.$_GET['pass'].'"}';
• Злоумышленник добавляет данные к своему имени пользователя:
  john%22,%22account%22:%22administrator%22
• Результирующая строка JSON:
  {
"account":"user",
"user":"john",
"account":"administrator",
"pass":"password"
}
• При чтении сохраненной строки парсер JSON (json_decode) обнаруживает две account-записи и берет последнюю, предоставляя права администратора пользователю john.

Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:

• Строка JSON такая же, как в приведенном выше примере;
• Сервер получает строку JSON из ненадежного источника;
• Клиент анализирует строку JSON, используя eval:
  var result = eval("(" + json_string + ")");
document.getElementById("#account").innerText = result.account;
document.getElementById("#user").innerText = result.name;
document.getElementById("#pass").innerText = result.pass;
• Значение account:
  user"});alert(document.cookie);({"account":"user
• Функция eval выполняет alert;
• Выполнение приводит к XSS и получению document.cookie.

JSON Hijacking

Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:

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

XML External Entity

Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.

XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.

Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.



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





/etc/fstab — это файл, содержащий некоторые символы, похожие на XML, но они не являются XML. Это заставит синтаксический XML-процессор пытаться анализировать эти элементы только для того, чтобы понять — это недействительный XML-документ. Таким образом, внедрение внешних объектов XML ограничивается двумя важными правилами:

• XXE можно использовать только для получения файлов или ответов, содержащих «действительный» XML;
• XXE нельзя использовать для получения двоичных файлов.

Обходные пути ограничения XML

Основная проблема для атакующего, использующего XXE, заключается в том, как получить доступ к текстовым файлам с XML-подобным содержимым (файлы, содержащие специальные символы XML, такие как ",',<,>). У XML есть способ решения этой проблемы. Если требуется хранить специальные символы XML в XML-файлах, их можно поместить в тегах CDATA (символьные данные), которые игнорируются анализатором XML:
<![CDATA["'<> characters are ok in here ]]>

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

Сущности параметров

Помимо общих сущностей, XML также поддерживает сущности параметров. Сущности параметров используются только в определениях типов документов (DTD). Сущность параметра начинается с символа %. Этот символ указывает синтаксическому анализатору XML, что определяется объект параметра. В следующем примере сущность параметра используется для определения общей сущности, которая затем вызывается из документа XML:



Таким образом, злоумышленник может взять неработающий пример с использованием CDATA, приведенный выше, и превратить его в рабочую атаку, создав вредоносный DTD и разместить его на своем сайте attacker.com/evil.dtd.


При этом DTD злоумышленника, находящийся в attacker.com/evil.dtd содержит:

<!ENTITY % file SYSTEM "file:///etc/fstab">
<!ENTITY % start "<![CDATA[">
<!ENTITY % end "]]>">
<!ENTITY % all "<!ENTITY fileContents
'%start;%file;%end;'>">

Когда злоумышленник отправляет вышеуказанный запрос, синтаксический анализатор XML сначала пытается обработать DTD-объект параметра, отправляя запрос на http://attacker.com/evil.dtd. После загрузки DTD злоумышленника анализатор XML загрузит из evil.dtd объект параметра %file, которым в данном случае является /etc/fstab. Затем он помещает содержимое файла в теги CDATA, используя объекты параметров %start и %end соответственно. Полученный результат сохраняется в еще одной вызываемой сущности параметра %all. Суть метода состоит в том, что в %all создается общая сущность с именем &fileContents, которую можно включить как часть ответа. Результатом является содержимое файла /etc/fstab, заключенное в теги CDATA.

Оболочки протокола PHP

Если веб-приложение, уязвимое для XXE, является приложением PHP, можно использовать другие векторы атак благодаря протоколу PHP. Оболочки протокола PHP — это потоки ввода-вывода, которые обеспечивают доступ к потокам ввода и вывода PHP. Злоумышленник может использовать оболочку протокола php://filter для кодирования содержимого файла в формате Base64. Поскольку Base64 всегда будет рассматриваться XML как допустимый, злоумышленник может просто закодировать файлы на сервере, а затем декодировать их на принимающей стороне. Этот метод дополнительно позволяет злоумышленнику получить еще и двоичные файлы.

Инструменты поиска уязвимостей

Инструментов поиска уязвимостей довольно много. Есть коммерческие продукты: Acunetix, Nessus Scanner, Nexpose, но имеющие и бесплатные пробные версии с ограниченным функционалом. А есть и полностью бесплатные: Wapiti, Nikto, Vega, SQLmap.

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

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

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

Wafw00f отправляет обычные HTTP-запросы и анализирует ответ от веб-приложения, позволяя идентифицировать ряд WAF. Если это не удается, отправляется группа потенциально вредоносных HTTP-запросов и используется простая логика для определения производителя WAF. Если и после этого не удается идентифицировать WAF, то анализируются ранее возвращенные ответы, но используется уже другой алгоритм. Метод, который использует Wafw00f для идентификации Nemesida WAF основывается на статусе ответа 222 и соответствующих регулярных выражениях:



Тем не менее, подобный подход не позволяет инструменту обнаружить Nemesida WAF:





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

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

Блокирование атак с помощью WAF

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

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

Если вы занимаетесь разработкой или обслуживанием веб-приложений и API, но не имеете возможность использовать полноценную версию Nemesida WAF, советуем попробовать его бесплатную версию на основе сигнатурного анализа — Nemesida WAF Free. Заблокированные атаки будут доступны в личном кабинете (устанавливается локально), а качественно написанная сигнатурная база способна выявить большинство известных атак.

Демонстрационный стенд Nemesida WAF:

Для наглядности, как в конечном счете будет выглядеть заблокированная атака, мы развернули стенд с личным кабинетом demo.lk.nemesida-security.com (user/pass: demo@pentestit.ru / pentestit). Личный кабинет предоставляется в виде установочного дистрибутива и также доступен для Nemesida WAF Free.

Nemesida WAF предоставляется в виде динамического модуля Nginx и может быть подключен к уже установленному экземпляру веб-сервера без его перекомпиляции. Быстрый старт занимает не более 5 минут для опытных пользователей продукта и не требует сложных настроек.

Инструкция по установке и первичной настройке Nemesida WAF Free доступна на официальном сайте или Github.