Привет, античат .

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

HTTP-методы.

Протокол HTTP имеет несколько методов, с помощью которых осуществляются действия на веб-сервере. В основном в веб-приложениях используются методы GET и POST, но существуют и другие, позволяющие манипулировать данными на сервере либо используемые для отладки приложения. Ниже список методов протокола HTTP версии 1.1, согласно стандарту RFC 2616 (RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1):

- HEAD
- GET
- POST
- OPTIONS
- PUT
- DELETE
- TRACE
- CONNECT

В контексте возможных уязвимостей нас больше всего интересуют следующие четыре метода:

PUT — позволяет загружать файлы на сервер. Злоумышленник может загрузить веб-шелл или использовать сервер просто в качестве файлового хранилища.
DELETE— позволяет удалять файлы с сервера. Тем самым злоумышленник может организовать DOS-атаку или удалить сайт.
CONNECT — позволяет использовать сервер как прокси-сервер.
TRACE— метод возвращает клиенту копию отправленного запроса и в основном используется для отладки приложения. Однако он так же позволяет провести атаку Cross-site-tracing или XST.

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

Как тестировать.

Определите все методы, которые поддерживаются сервером. Наиболее тривиальный способ — это использовать метод OPTIONS, который возвращает список всех доступных методов. Ниже пример, как это можно сделать с netcat:


Из ответа можем видеть, что сервер поддерживает методы OPTIONS, TRACE, GET, HEAD, POST.

Тоже самое можно сделать с помощью nmap и NSE-скриптаhttp-methods:



Попробуем использовать метод TRACE:


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

Атака XST.

Чтобы понять логику и цели этой атаки, нужно понимать логику и цели атаки XSS.
XSS (межсайтовый скриптинг) — это атака, при которой в веб-страницу, выдаваемую жертве, внедряется вредоносный скрипт, обычно на языке javascript. Часто целью данной атаки являются файлы cookie, принадлежащие жертве. Вредоносный скрипт, выполняясь в браузере жертвы, ворует cookie жертвы и отправляет их злоумышленнику, который таким образом угоняет сессию у жертвы. Но когда в заголовке cookie установлен флаг HttpOnly, браузер не отдает cookie js-скриптам, тем самым предотвращая их кражу. Метод TRACE позволяет обойти это ограничение.

Посмотрим на скриншот. Как мы помним, при использовании метода TRACE сервер возвращает в браузер точную копию отправленного запроса:



В теле ответа вернулись и cookie вместе с флагом HttpOnly. В этом случае вредоносный js-скрипт сворует cookie по такой схеме:

1. Скрипт cформирует TRACE-запрос и отправит его из браузера жертвы на сервер.
2. Если в браузере жертвы имеются cookie для данного сервера, они автоматически будут включены в запрос. Следовательно они будут включены и в ответ сервера.
3. Затем скрипт считает ответ сервера и из тела ответа извлечет данные о cookie и другую необходимую информацию без ограничений.

Есть два сценария осуществления этой атаки. В первом сценарии атакующий, наряду с методом TRACE, должен использовать обычную XSS-уязвимость.
Во втором сценарии атакующий может сам создать вредоносный сайт и заставить жертву перейти на этот сайт. Используя некую кроссдоменную уязвимость браузера жертвы, js-скрипт на вредоносном сайте инициирует соединение с сайтом, поддерживающем TRACE, и получет cookie жертвы. Более подробно об атаке XST рекомендуется почитать в этом документе — https://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf.

Тестирование произвольных HTTP-методов.

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

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

И так, на тестируемом сайте могут быть страницы, которые недоступны обычным юзерам и возвращают ошибки при попытке доступа к ним. При попытке доступа к административным функциям вы можете получать ответ с кодом 302 (редирект на страницу логина, к примеру) или с кодом 403 (доступ запрещен). В этом случае попробуйте в запросе использовать другой метод. Если по умолчанию используется метод GET, попробуйте HEAD, или любой другой метод.

Пример. Запросы GET и HEAD возвращают ошибку 403 (доступ запрещен):





Метод PUT возвращает ошибку 405:



Несуществующий метод CAT возвращает ошибку 501:


А метод OPTIONS возвращает код 200:


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

Эта техника атаки называетсяHTTP Verb Tampering. Подробнее об атаке будет в одной из следующих статей, когда будем рассматривать инъекции.

HTTP Strict Transport Security (HSTS).

HTTP Strict Transport Security — это такой механизм, с помощью которого веб-приложение сообщает браузеру, что все соединения между приложением и браузером должны принудительно использовать HTTPS. Если в ответе сервера есть заголовок Strict-Transport-Security, то все соединения будут принудительно шифроваться, даже если пользователь случайно или намеренно пытается использовать протокол HTTP:


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

Кроссдоменная политика.

Веб-приложение может давать доступ к своим ресурсам из другого домена, если на том другом домене используются такие технологии, как Oracle Java, Silverlight и Adobe Flash. Регулируется этот доступ с помощью файла crossdomain.xml, который должен находится в корне сайта.

В файле crossdomain.xml на скрине ниже указано, каким доменам можно получать ресурсы с Твиттер:


В этом случае доступ позволен с любого домена:


Для Silverlight так же используется crossdomain.xml от Adobe и дополнительно Microsoft создала собственный файл политики clientaccesspolicy.xml:


Файл crossdomain.xml для Silverlight работает только в том случае, если в нем разрешен доступ с любых доменов, clientaccesspolicy.xml используется для более детальной настройки политик.

Чрезмерно разрешающие файлы политик кросдоменных запросов могут способствовать CSRF-подобным атакам. Представим такой случай: имеется сайт victim.com, в корне которого лежит файл crossdomain.xml, который разрешает доступ к своим ресурсам с любых доменов, как тут:


Хакер создает сайт evil.hack, размещает на нем специально созданое Flash-приложение. Затем он каким-то образом заманивает жертву на свой сайт. Когда жертва переходит на сайт evil.hack, флэш-приложение создает запрос от имени жертвы к сайту victim.com и выполняет на нем какие-то вредоносные действия, так же от имени жертвы.

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

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

Права доступа к файлам и директориям.

Тестирование прав доступа можно провести только по методу Grey Box или White Box, то есть когда у пентестера есть частичный или полный доступ к тестируемой системе изнутри. При методе Black Box данный тест неприменим.

Права доступа должны быть настроены по принципу наименьших прав.

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

Для того, что бы узнать права доступа в linux, можно воспользоваться командой ls:


или командой namei:


В большинстве случаев права должны быть выставлены следующим образом:

Скрипты и директории для скриптовrwx-wx---Файлы конфигурацииrw-------Директории с файлами конфигурацииrwx------Лог-файлыrw-r-----Архивы лог файловr--------Директории лог-файловrwx------Файлы отладкиrw-------Директории с отладочными файламиrwx------Файлы баз данныхrw-------Директории баз данныхrwx------Файлы с приватной информацией (ключи, пароли и т.д.)rw-------

На сегодня всё, всем пока )