|
Привет, античат .
В этой статье определим, какие 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: https://forum.antichat.xyz/attachmen...90454f6c0f.png Из ответа можем видеть, что сервер поддерживает методы OPTIONS, TRACE, GET, HEAD, POST. Тоже самое можно сделать с помощью nmap и NSE-скриптаhttp-methods: https://forum.antichat.xyz/attachmen...ce3cedeb7d.png Попробуем использовать метод TRACE: https://forum.antichat.xyz/attachmen...a1ef4dd4e4.png Внезапно сервер отвечает ошибкой 501 - метод не реализован, хотя в предыдущих примерах мы видим, что TRACE в списке поддерживаемых. Такое поведение может указывать на то, что между нами и веб-сервером находится прокси-сервер. Атака XST. Чтобы понять логику и цели этой атаки, нужно понимать логику и цели атаки XSS. XSS (межсайтовый скриптинг) — это атака, при которой в веб-страницу, выдаваемую жертве, внедряется вредоносный скрипт, обычно на языке javascript. Часто целью данной атаки являются файлы cookie, принадлежащие жертве. Вредоносный скрипт, выполняясь в браузере жертвы, ворует cookie жертвы и отправляет их злоумышленнику, который таким образом угоняет сессию у жертвы. Но когда в заголовке cookie установлен флаг HttpOnly, браузер не отдает cookie js-скриптам, тем самым предотвращая их кражу. Метод TRACE позволяет обойти это ограничение. Посмотрим на скриншот. Как мы помним, при использовании метода TRACE сервер возвращает в браузер точную копию отправленного запроса: https://forum.antichat.xyz/attachmen...109c2dd6dc.png В теле ответа вернулись и 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 (доступ запрещен): https://forum.antichat.xyz/attachmen...20cd483b1a.png https://forum.antichat.xyz/attachmen...07587d3e86.png Метод PUT возвращает ошибку 405: https://forum.antichat.xyz/attachmen...de351a5698.png Несуществующий метод CAT возвращает ошибку 501: https://forum.antichat.xyz/attachmen...1c775d3955.png А метод OPTIONS возвращает код 200: https://forum.antichat.xyz/attachmen...277cd9c31e.png Таким образом метод OPTIONS позволяет обойти запрет на выполнение каких либо действий. К примеру, если мы найдем в тестируемом приложении файл deleteUser.jsp, доступ к которому будет ограничен, то, выполнив обращение к этому файлу с методом OPTIONS, мы сможем получить доступ к функционалу этого файла и удалить какого-нибудь юзера из приложения, не имея на то никаких полномочий. Эта техника атаки называетсяHTTP Verb Tampering. Подробнее об атаке будет в одной из следующих статей, когда будем рассматривать инъекции. HTTP Strict Transport Security (HSTS). HTTP Strict Transport Security — это такой механизм, с помощью которого веб-приложение сообщает браузеру, что все соединения между приложением и браузером должны принудительно использовать HTTPS. Если в ответе сервера есть заголовок Strict-Transport-Security, то все соединения будут принудительно шифроваться, даже если пользователь случайно или намеренно пытается использовать протокол HTTP: https://forum.antichat.xyz/attachmen...6bec4743a7.png ПолеincludeSubDomains указывает, что трафик будет шифроваться так же и для субдоменов. HSTS снижает угрозу прослушки трафика и кражи cookie и других важных данных, поэтому при тестировании приложений необходимо проверить, включен ли данный механизм. Кроссдоменная политика. Веб-приложение может давать доступ к своим ресурсам из другого домена, если на том другом домене используются такие технологии, как Oracle Java, Silverlight и Adobe Flash. Регулируется этот доступ с помощью файла crossdomain.xml, который должен находится в корне сайта. В файле crossdomain.xml на скрине ниже указано, каким доменам можно получать ресурсы с Твиттер: https://forum.antichat.xyz/attachmen...825b84ce6f.png В этом случае доступ позволен с любого домена: https://forum.antichat.xyz/attachmen...d5a7e9b4ef.png Для Silverlight так же используется crossdomain.xml от Adobe и дополнительно Microsoft создала собственный файл политики clientaccesspolicy.xml: https://forum.antichat.xyz/attachmen...6acd5af570.png Файл crossdomain.xml для Silverlight работает только в том случае, если в нем разрешен доступ с любых доменов, clientaccesspolicy.xml используется для более детальной настройки политик. Чрезмерно разрешающие файлы политик кросдоменных запросов могут способствовать CSRF-подобным атакам. Представим такой случай: имеется сайт victim.com, в корне которого лежит файл crossdomain.xml, который разрешает доступ к своим ресурсам с любых доменов, как тут: https://forum.antichat.xyz/attachmen...a24fea1569.png Хакер создает сайт evil.hack, размещает на нем специально созданое Flash-приложение. Затем он каким-то образом заманивает жертву на свой сайт. Когда жертва переходит на сайт evil.hack, флэш-приложение создает запрос от имени жертвы к сайту victim.com и выполняет на нем какие-то вредоносные действия, так же от имени жертвы. Подобная уязвимость когда-то давно имелась на сайте Хабрахабр. В статье - CSRF уязвимости на примере ХабраХабра автор рассказывает об уязвимости и показывает, как ее можно эксплуатировать. Файлы кроссдоменных политик могут находиться и в других директориях, но их использование должно быть разрешено основным файлом crossdomain.xml, который находится в корне веб-сайта. В ходе тестирования попытайтесь найти все файлы кросдоменных политик и определить, не представляют ли их разрешения угрозу веб-приложению. Кросдоменная политика должна разрешать доступ к ресурсам приложения по принципу наименьших прав, то есть разрешать запросы только с тех доменов, и только по тем протоколам, которые необходимы. Права доступа к файлам и директориям. Тестирование прав доступа можно провести только по методу Grey Box или White Box, то есть когда у пентестера есть частичный или полный доступ к тестируемой системе изнутри. При методе Black Box данный тест неприменим. Права доступа должны быть настроены по принципу наименьших прав. Что следует проверить: - веб-файлы и веб-каталоги - конфигурационные файлы - файлы и каталоги с чувствительными данными (ключи, пароли, зашифрованные данные) - лог-файлы - исполняемые файлы и каталоги с ними - файлы и каталоги баз данных - временные файлы и каталоги - каталоги для загрузки файлов Для того, что бы узнать права доступа в linux, можно воспользоваться командой ls: https://forum.antichat.xyz/attachmen...db89a2a821.png или командой namei: https://forum.antichat.xyz/attachmen...eac2b2dbfd.png В большинстве случаев права должны быть выставлены следующим образом: Скрипты и директории для скриптовrwx-wx---Файлы конфигурацииrw-------Директории с файлами конфигурацииrwx------Лог-файлыrw-r-----Архивы лог файловr--------Директории лог-файловrwx------Файлы отладкиrw-------Директории с отладочными файламиrwx------Файлы баз данныхrw-------Директории баз данныхrwx------Файлы с приватной информацией (ключи, пароли и т.д.)rw------- На сегодня всё, всем пока ) |
| Время: 17:41 |