Привет, codeby.
В этой статье определим, какие HTTP-методы поддерживаются веб-сервером; узнаем, как метод TRACE связан с атакой XST; определим, включен ли на сервере механизм HSTS; поговорим о кроссдоменной политике и о правах доступа к файлам на сервере.
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
codeby.net
HTTP-методы.
Протокол HTTP имеет несколько методов, с помощью которых осуществляются действия на веб-сервере. В основном в веб-приложениях используются методы GET и POST, но существуют и другие, позволяющие манипулировать данными на сервере либо используемые для отладки приложения. Ниже список методов протокола HTTP версии 1.1, согласно стандарту RFC 2616 (
- 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 рекомендуется почитать в этом документе —
Тестирование произвольных 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:
В большинстве случаев права должны быть выставлены следующим образом:
На сегодня всё, всем пока )
В этой статье определим, какие HTTP-методы поддерживаются веб-сервером; узнаем, как метод TRACE связан с атакой XST; определим, включен ли на сервере механизм HSTS; поговорим о кроссдоменной политике и о правах доступа к файлам на сервере.
Как стать хакером и как взломать сайт или беглое знакомство с OWASP Testing Guide
В этой статье я попробую ответить на два самых часто задаваемых вопроса на тематических форумах
Введение в пентест веб-приложений: поиск утечек информации с помощью поисковых систем
Сегодня получим небольшую дозу теории и приступим к практической части
Пентест веб приложений: определение веб-сервера, изучение robots.txt, определение приложений на веб-сервере.
Сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на robots.txt.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
При тестировании веб-приложений методом BlackBox у нас, как правило, не будет доступа ко всем исходным кодам приложения
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Сегодня мы научимся определять фреймворк и веб-приложение, а так же составим карту архитектуры приложения
Пентест веб-приложений: Тестирование конфигурации инфраструктуры приложения. Расширения файлов.
Тестирование безопасности платформы, на которой развернуто веб-приложение
Пентест веб-приложений: Обнаружение резервных копий, старых и забытых файлов. Поиск административных интерфейсов и подбор паролей к ним.
В данной статье будет рассмотрена тема забытых файлов на сервере, устаревших файлов, бэкапов, временых файлов
HTTP-методы.
Протокол HTTP имеет несколько методов, с помощью которых осуществляются действия на веб-сервере. В основном в веб-приложениях используются методы GET и POST, но существуют и другие, позволяющие манипулировать данными на сервере либо используемые для отладки приложения. Ниже список методов протокола HTTP версии 1.1, согласно стандарту RFC 2616 (
Ссылка скрыта от гостей
):- 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 рекомендуется почитать в этом документе —
Ссылка скрыта от гостей
.Тестирование произвольных 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------- |
На сегодня всё, всем пока )
Последнее редактирование:
