Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о тестировании HTTP методов.
[spoiler title=’Предыдущие части’ style=’default’ collapse_link=’true’]

  1. Тестирование: введение и задачи
  2. Сбор информации с помощью поисковых систем
  3. Определение веб-сервера
  4. Поиск информации в метафайлах веб-сервера
  5. Определение веб-приложений на сервере
  6. Поиск утечек информации в комментариях и метаданных
  7. Определение точек входа веб-приложения
  8. Составление карты веб-приложения
  9. Определение фреймворка веб-приложения
  10. Определение веб-приложения
  11. Составление карты архитектуры веб-приложения
  12. Тестирование конфигурации инфраструктуры веб-приложения
  13. Изучение расширений файлов
  14. Поиск страрых версий веб-приложения, скрытых файлов и резервных копий
  15. Поиск административных интерфейсов

[/spoiler]

Резюме

HTTP предоставляет несколько методов, которые могут быть использованы для взаимодействия с веб-сервером. Многие из этих методов созданы для помощи разработчикам в разворачивании и тестировании веб-приложений. Но также эти методы могут быть использованы в гнусных целях, если веб-сервер неверно сконфигурирован.
Методы GET и POST пожалуй самые популярные и самые используемые методы для взаимодействия с веб-сервером. Протокол HTTP, описанный в  (описывает версию протокола HTTP 1.1) поддерживает следующие 8 методов:

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

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

  • PUT — этот метод позволяет клиентам загружать новые файлы на веб-сервер. Атакующий может использовать это для загрузки опасных файлов (например, asp-файл, исполняющий команды посредством вызова cmd.exe), или просто использовать веб-сервер в качестве файлового хранилища;
  • DELETE — этот метод позволяет клиентам удалять файлы, хранящиеся на веб-сервере. Атакующий может просто удалить важные файлы или устроить DoS атаку на веб-сервер;
  • CONNECT — этот метод может позволить клиентам использовать веб-сервер в качестве прокси-сервера.
  • TRACE — этот метод возвращает в ответе клиенту строку, которая была ему послана и используется в большинстве случаев для отладки. Но также этот метод может быть использован для проведения атаки Cross Site Tracing (XST).

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

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

  • многие фреймворки трактуют метод HEAD как GET запрос. Если для метода GET были установлены ограничения, например метод GET могут использовать только аутентифицированые пользователи и только для определенных ресурсов, такое ограничение можно обойти при использовании метода HEAD вместо GET. Это ведет к возможности неавторизованного слепого определения привилегированных GET запросов.
  • некоторые фреймворки позволяют использовать случайные HTTP методы, такие как JEFF или CATS. Такие методы трактуются как GET и их использование позволяет в некоторых случая обойти ограничения безопасности или проверки контроля доступа для используемых HTTP методов

В большинстве случаев, явной проверки использования методов GET или POST достаточно, чтобы нейтрализовать описанные выше случаи.

Как тестировать
Определение поддерживаемых методов
Тестировщику необходимо определить, какие HTTP методы поддерживаеются веб-сервером. Метод OPTIONS — прямой и самый эффективный способ. Согласно RFC 2616, метод OPTIONS представляет собой запрос информации о возможных способах взаимодействия с веб-сервером.
Такой способ тестирования самый простой и требует лишь наличия netcat (или telnet):


$ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

Как видно из примера, метод OPTIONS предоставляет нам информацию обо всех доступных методах взаимодействия с веб-сервером. В данном случае, нам доступен метод TRACE. Опасность, которую он представляет, будет описана в соответствующей секции.
Такой же тест может быть проведен и с помощью утилиты nmap и NSE скрипта http-methods:


C:\Tools\nmap-6.40>nmap -p 443 --script http-methods localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time

Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT    STATE SERVICE
443/tcp open  https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds

Проверка наличия XST

Для понимания логики атаки, рекомендуется ознакомиться с Cross Site Scripting attacks
Метод TRACE в некоторых случаях может быть использован для кражи учетных данных пользователей. Эта техника атаки была открыта Jeremiah Grossman в 2003 в попытке обойти тэг HTTPOnly, представленный Microsoft в Internet Explorer 6 SP1 для запрета доступа к кукам из JavaScript. Один из самых популярных сценариев атак типа Cross Site Scripting — получение доступа к объекту document.cookie и отправке его содержимого на веб-сервер, контролируемый злоумышленником для дальнейшего использования сессии жертвы. Куки, помеченные тэгом httpOnly недоступны из JavaScript, что делает невозможным их похищение. Однако, метод TRACE может быть использован для обхода такой защиты.
Как упоминалось ранее, метод TRACE просто возвращает строку, посланную веб-серверу. Пример:


$ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com

Тело ответа — точная копия оригинального запроса. Теперь, если тестировщик заставит браузер выполнить TRACE запрос к веб-серверу и в браузере имеются куки для этого домена, эти куки будут автоматически включены в посылаемый запрос и будут возвращены веб-сервером в ответе, таким образом все же можно будет получить доступ к кукам из JavaScript, обработав ответ от веб-сервера, даже если куки помечены тегом httpOnly.
Есть несколько способов заставить браузер выполнить TRACE запрос, например использовать XMLHTTP ActiveX в Internet Explorer или XMLDOM в Mozilla и Netscape. Однако, ограничения безопасности позволяют браузеру подключаться только к домену на котором находится вредоносный скрипт, это нейтрализующий фактор, поэтому атакующему необходимо комбинировать TRACE метод c другими уязвимостями для успешного проведения атаки.
Атакующий имеет 2 пути для успешной реализации XST атаки:

  • используя другую серверную уязвимость: атакующий встраивает вредоносный скрипт, содержащий TRACE запрос, в веб-приложение, как и в обычной XSS атаке.
  • воздействуя на клиента: атакующий создает веб-сайт, содержащий вредоносный скрипт, и использует какие-либо кросс-доменные уязвимости браузера жертвы, вынуждает его установить соединение с целевым веб-приложением

Тестирование случайных HTTP методов
Необходимо найти страницу, имеющую ограничения на доступ, которая перенаправляет пользователя на страницу логина (HTTP 302) или предлагает выполнить вход. Если при использовании случайных HTTP методов при запросе этой страницы веб-сервер возвращает код 200, значит возможен обход аутентификации.


$ nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW…

Если фреймворк или файрвол или приложение не поддерживает JEFF метод, ему следует возвращать страницу ошибки (или предпочтительно 405 Not Allowed или 501 Not Implemented). Если же такой запрос успешно обрабатывается, значит приложение уязвимо.
Если тестировщик понимает, что система уязвима к данному типу атаки, ему следует применить CSRF-подобные атаки, модифицированные под тестируемое приложение:

  • FOOBAR /admin/createUser.php?member=myAdmin
  • JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
  • CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

Тестирование обхода контроля доступа с помощью метода HEAD
Условия тестирования в данном случае совпадают с предыдущими — необходимо найти страницу, имеющую ограничения на доступ, которая перенаправляет пользователя на страницу логина (HTTP 302) и протестировать эту страницу с помощью метода HEAD:


$ nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi…; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=…; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=…; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=…; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Если будет получен ответ “405 Method not allowed” или “501 Method Unimplemented”, значит целевая система (приложение/фреймворк/файрвол) работает корректно. Если же получен ответ с кодом 200, вероятно, что приложение обработало запрос без аутентификации и авторизации, требуется дальнейшее тестирование.
Для тестирования можно попробовать применить CSRF-подобные атаки, модифицированные под тестируемое приложение:

  • HEAD /admin/createUser.php?member=myAdmin
  • HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
  • HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

Инструменты:

Справочные материалы: