Как уже было сказано, общение между клиентом HTTP и сервером происходит посредством отправки запросов и получения ответов. Каждый HTTP-запрос состоит из четырех частей, которые передаются в указанном порядке: Строка запроса (Request line). Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения. Пустая строка. Тело сообщения (Message Body) — непосредственно данные сообщения.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. В строке запроса обязательно указывается один из методов (Method), который отображает суть запроса. С ними нужно разобраться особенно четко, чтобы не осталось ничего неясного. В описании протокола HTTP (RFC 2616) заявлены следующие методы:
Запрос GET. Наиболее популярный и знакомый всем метод. Именно GET применяется при открытии любого ресурса или скачивании файла. Метод используется для запроса конкретного объекта на конкретном ресурсе. Различают conditional GET (зависит от выполнения определенных условий) и partitional GET (если часть информации уже имеется и закэширована и требуется докачать недостающее).
Запрос OPTIONS. Метод служит для опроса сервера о его возможностях. Позволяет клиенту определить опции и/или требования, связанные с ресурсом, а также информацию о возможных способах общения клиента и сервера. Как правило, доступные методы на сервере можно получить путем анализа поля Allow. Ниже – пример с Netcat:
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 1 Sep 2008 08:00:29 GMT Connection: close Allow: GET, HEAD, POST, TRACE, OPTIONS Content-Length: 0
Это очень удобно, так как избавляет тебя от проверки всех возможных вариаций и получения кодов ответа после их выполнения. О доступных методах важно знать, потому что некоторые из них небезопасны. К примеру, с методами TRACK/TRACE есть возможность произвести хищение куков с использованием известного приема Cross-Site Tracing. Впрочем, это уже разговор для отдельной статьи.
Запрос HEAD. Перед нами клон GET с той лишь разницей, что сервер будет возвращать только специальную служебную информацию, связанную с запрошенным документом, а тело сообщения будет отсутствовать. В хакерских целях метод используется для проверки наличия директорий на удаленном сервере. Для этого требуется подготовить список директорий и закидывать сервер по следующему алгоритму: посылаем HEAD с указанием пути искомой директории, ждем выполнения запроса, проверяем статус ответа: если он равен 200 (ОК) и мета-данные присутствуют, то директория с большой долей вероятности существует на сервере.
Запрос POST. Этот метод используется в случаях отправки сообщений и передачи данных. Тело запроса передается серверу, и тот интерпретирует его в зависимости от URI запроса. URI – это стандарт формата, используемого для определения извлекаемого ресурса. В подмножество URI входит URL/URN.
Запрос PUT. Метод PUT используется для создания нового объекта с заданным в запросе URI. Если ресурс с таким URI уже существует, то тело запроса рассматривается как его обновленная версия. Один из примеров использования – простая выгрузка файла на сервер (создание нового файла, замена существующего).
Запрос DELETE. Метод DELETE используется для удаления ресурса под заданный URI. В этой ситуации сервер часто просит подтверждения действия. Запрос TRACE. Метод TRACE используется в целях отладки и диагностики. С его помощью можно удостовериться, были ли данные действительно приняты адресатом запроса.
Запрос CONNECT. Имя этого метода зарезервировано для прокси-серверов, которые могут динамически становиться туннелями (к примеру, SSL). Техника HTTP-printing
Приемов для определения WEB-сервера и его конкретной версии довольно много. Из основных можно выделить: «прямой» просмотр поля «Server», получаемого из Response-ответа после отправки запроса GET; изучение того же поля после серии запросов других методов, в том числе и ошибочных; анализ кодов ошибок, высылаемых в качестве статуса выполнения метода; сравнение шаблона favicon.ico для конкретного сервера с удаленным; структура высылаемого Response-ответа.
Подробнее рассмотрим некоторые из них. Анализ поля «Server» в ответе сервера (пример ответа можно увидеть выше) — это самый простой вариант, однако администратору ничего не стоит заменить информацию в этом поле. Но если верить стандарту, то в этом поле содержится информация об используемом программном обеспечении в том виде, в котором это указывает сам WEB-сервер. Например, известный HTTP-демон Apache имеет несколько видов отдачи информации о себе: Prod (Apache), Min (Apache/1.3.0), Major (Apache/1), Minor (Apache/1.3), OS (Apache/1.3.0 (UNIX)), Full (Apache/1.3.0 (UNIX) mod_fastcgi/2.4.2 mod_perl/2.0.2 Perl/v5.8.7). Стоит заметить, что в конфигурационных файлах можно отключить отображение названия и версии демона. До версии 2.0.44 такая директива называлась ServerSignature и находилась в httpd.conf. В старших версиях этой ветки, директива носит название ServerTokens. В статье «Сетевой камуфляж» приводились примеры и способы скрытия демонов, в том числе распространяющиеся на WEB-серверы.
Коды ошибок (они же – статусы выполнения) – еще один способ узнать некоторые данные о сервере. Метод, который считается очень точным, может служить в качестве дополнительного эвристического теста. Нарушить детектирование можно с помощью редактирования исходных кодов или конфигов. WEB-сервер Apache имеет для этого следующие директивы: LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine. Хотя, конечно, их прямое назначение заключается совсем в другом: они нужны для снижения вероятности DDoS-атак на сервер с помощью аномальных запросов.
Иконка сервера – деталь, казалось бы, незаметная. Но и она способна выдать тот или иной демон. При первоначальной установке многие WEB-сервисы по умолчанию устанавливают тестовый сайт, где отображается автоматическое приветствие и favicon. Почему бы это не проанализировать? Предварительно можно написать небольшой скрипт для получения хэш-суммы favicon. Натравить его на иконку из локального пакета и затем сравнивать с хеш-суммами иконок с удаленных серверов, где администраторы из-за рассеянности забыли удалить тестовую иконку и страницы документации. Вот пример подобного скрипта на Python:
import md5 m = md5.new() f = file('file.ico', 'r') while True: t = f.read(1024) if len(t) == 0: break m.update(t) print m.hexdigest()
Практика показывает, что таким образом можно отличить продукты одной семьи, но разных версий (или предназначенные для разных платформ):
31aa07fe236ee504c890a61d1f7f0a97 - Apache 2.2.4 d41d8cd98f00b204e9800998ecf84275 - Apache HTTP Server (Mac OS X Server) Юзаем специальный софт
К сожалению, на сегодняшний день средства для HTTP-printing’а не столь разнообразны. Из инструментов наиболее известны HTTPrint (net-square.com/httprint/) и HMAP (ujeni.murkyroc.com/hmap/). Создатели первого заявляют, что их проект способен распознавать сервера даже с измененной версией. Здесь используется целый ряд эвристических тестов, некоторые из которых были описаны в этой статье. А пакет HMAP на текущий момент является плагином к известному сканеру безопасности NESSUS, бесплатный форк которого называется OpenVAS (Open Vulnerability System).
Создатели обоих инструментов сильно заморачивались, чтобы добиться как можно более четкого и правдоподобного определения удаленного веб-сервера. Но далеко не всегда подобный софт сможет помочь при анализе наиболее интересных и защищенных ресурсов. Тогда придется действовать вручную, используя вспомогательные инструменты типа Tamper Data (tamperdata.mozdev.org), Ratproxy (code.google.com/p/ratproxy).
Иногда серьезную помощь могут оказать всевозможные веб-сервесы. К примеру, сервис NetCraft ведет статистику об используемых продуктах на различных хостах во всем мире. Естественно, это нам на руку. Допустим, сервер ЦРУ (cia.gov) режет все аномальные запросы к нему и не выдает ни одного баннера сервиса. Как быть? Вбиваем адрес амеров в вышеназванную ссылку и получаем следующие данные за один из годов: Solaris 8, Netscape-Enterprise/4.1. Словом, способы могут быть самые разные! Где искать веб-сервер
Перед началом анализа WEB-сервера неплохо выяснить, на каком порту он установлен. Ведь работать он может не только на стандартном 80 порту. Если картина с самого начала не ясна, лучше просканировать порты удаленного сервера. Варианты следующие:
http 80/tcp http-mgmt 280/tcp http-ssl 443/tcp gss-http 488/tcp http-alt 591/tcp # FileMaker, Inc. - HTTP Alternate http-rpc-epmap 593/tcp # HTTP RPC Ep Map NFS-or-IIS 1025/tcp # IIS, NFS, or listener RFS remote_file_sharing IIS 1027/tcp compaqdiag 2301/tcp # Compaq remote diagnostic/management squid-http 3128/tcp # Squid HTTP Proxy or MS ISA proxy-plus 4480/tcp # Proxy+ HTTP proxy port vnc-http 5800/tcp # Virtual Network Computer HTTP Access, display 0 vnc-http-1 5801/tcp # Virtual Network Computer HTTP Access, display 1 vnc-http-2 5802/tcp # Virtual Network Computer HTTP Access, display 2 vnc-http-3 5803/tcp # Virtual Network Computer HTTP Access, display 3 analogx 6588/tcp # AnalogX HTTP proxy port weblogic 7001/tcp # Weblogic weblogic-ssl 7002/tcp # Weblogic SSL http-alt 8000/tcp http-alt 8001/tcp http-alt 8002 (+9090)/tcp http-proxy 8080/tcp # Common HTTP proxy/second web server port sun-answerbook 8888/tcp # Sun Answerbook HTTP server Расширения HTTP
Кроме HTTP-методов, описанных в RFC, существует и множество других. Самые интересные связаны с расширениями HTTP. Например, одно из них – WebDav, предоставляющее удобные механизмы для доступа к файлам и коллекциям, добавляет следующие заголовки и методы: PROPFIND. Получает свойства ресурса (PROPerties find). WebDav позволяет работать с файлами (в том числе, одновременно и распределено), например, выполнять их блокировку, и организовывать сетевую файловую систему. Метод служит для получения характеристик объекта. Кстати, в Subversion используется именно WebDav; PROPPATCH. Предназначен для добавления, удаления или изменения свойств ресурса; MKCOL. Создает новую коллекцию объектов:
