ТЕХНИКА СЕТЕВЫХ АТАК - Крис Касперский

Если возникнут затруднения с определением поля “Content-length”, задающим длину строки параметров (что особенно характерно для работы в telnet-клиенте), ее можно взять «с запасом», заполнив оставшийся конец мусором.

Метод POST позволяет передавать на сервер сообщения практически неограниченной длины, [271] поэтому, он позволяет организовать HTTP-закачку файлов на сервер, даже в том случае, когда метод PUT недоступен.

Метод DELETE, как и следует из его названия, предназначен для удаления ресурсов с сервера, однако, очень трудно представить себе администратора который бы допускал ее выполнение неавторизованным пользователям. Тщательные поиски так и не помогли найти ни одного примера в сети для демонстрации, поэтому придется ограничиваться «голой» теорией [272].

На этом описание методов протокола HTTP пришлось бы и закончить, если бы в 1996 году не появилась новая, значительно улучшенная спецификация - HTTP/1.1. Подробно все нововведения описаны в RFC-2068, здесь же будут перечислены лишь основные моменты.

Врезка «замечание»

Спецификация HTTP/1.0 поддерживает метод HEAD, который аналогичен GET, но возвращает лишь заголовок ответа, без тела сообщения.

Как правило, он используется для быстрой проверки доступности ресурса, что делает его привлекательным кандидатом на роль переборщика имен файлов, в надежде получить несанкционированный доступ к данным, «защита» которых базируется на одном лишь засекречивании ссылок. Удивительно, но такая атака часто срабатывает.

Прежде всего, требует пояснения ситуация, связанная с попыткой использования любого метода, с указанием номера новой версии. Например, на запрос “GET /~kpnc/ HTTP/1.1” сервер возвратит сообщение об ошибке 400 - “неверный запрос”. Такая ситуация продемонстрирована в примере, приведенном ниже:

·

GET /~kpnc/ HTTP/1.1·· HTTP/1.1 400 Bad Request· Date: Tue, 18 Apr 2000 14:18:41 GMT· Server: Apache/1.3.6 (Unix)· Connection: close· Transfer-Encoding: chunked· Content-Type: text/html·· 184· «!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"»· «HTML»· «HEAD»· «TITLE» 400 Bad Request «/TITLE»· «/HEAD»· «BODY»· «H1» Bad Request «/H1»· Your browser sent a request that this server could not understand.«P»· client sent HTTP/1.1 request without hostname· ( see RFC2068 section 9, and 14.23 ): /~kpnc/«P»· «HR»· «ADDRESS»Apache/1.3.6 Server at lightning.prohosting.com Port 80«/ADDRESS»· «/BODY»· «/HTML»

 Ознакомившись с ответом сервера, мысленно поблагодарим разработчиков за разъяснение причин отказа в обслуживании. Открыв секцию 14.23 технической документации RFC-2068, можно узнать, что, начиная с версии 1.1, становиться обязательным поле “Host”, содержащее базовый адрес и порт узла. (“If the Host field is not already present… all Internet-based “HTTP/1.1” servers MUST respond with a 400 status code to any “HTTP/1.1” request message which lacks a Host header field”). Впрочем, указывать порт необязательно, при его отсутствии сервер использует значение по умолчанию [273]. Такой механизм позволяет отличать gateway-серверам внутренние ссылки от внешних, оптимизируя сетевой трафик.

Поэтому, запрос должен выглядеть приблизительно следующим образом (необходимые пояснения даны ниже):

· ; Подключение узлу kpnc . softclub . net· TRACE /hello HTTP/1.1· Host:kpnc.softclub.net·· HTTP/1.1 200 OK· Date: Tue, 18 Apr 2000 18:37:47 GMT· Server: Apache/1.3.12 (Unix) mod_perl/1.22 AuthMySQL Plus/2.20.2 PHP/3.0.14 rus/PL29.4· Transfer-Encoding: chunked· Content-Type: message/http·· 32· TRACE /hello HTTP/1.1· Host: kpnc.softclub.net

Метод TRACE [274] очень сильно напоминает Echo (эхо), используемое для тестирования качества линии связи и быстроты реакции сервера. Получив TRACE-запрос, узел должен немедленно вернуть его отправителю, указав в факультативном [275] поле “Age” количество секунд, потраченных сервером на обработку запроса. Это позволяет администраторам инспектировать сетевой трафик, пользователям - выбирать быстрейший сервер из нескольких зеркал, а злоумышленникам оценивать пагубность влияния различных запросов на сервер, направленных на попытку добиться отказа в обслуживании.

Врезка «информация»

На сегодняшний день большинство серверов не поддерживают спецификацию ниже HTTP/1.1, отказываясь обслуживать устаревшего клиента. www.prohosting.com - один из немногих, которых удалось найти автору этой книги для демонстрации запросов HTTP/0.9 и HTTP/1.0

Дополнительная информация о сервере может быть получена с помощью метода “OPTIONS” с указанием символа-джокера вместо имени ресурса (возвратить всю доступную информацию).

Например:

· OPTIONS * HTTP/1.1· Host:kpnc.softclub.net·· HTTP/1.1 200 OK· Date: Tue, 18 Apr 2000 19:00:58 GMT· Server: Apache/1.3.12 (Unix) mod_perl/1.22 AuthMySQL Plus/2.20.2 PHP/3.0.14 rus/PL29.4· Content-Length: 0· Allow: GET, HEAD, OPTIONS, TRACE

В приведенном примере сервером сообщается установленное на нем программное обеспечение (вплоть до версии реализации) и разрешенные методы - GET, HEAD, OPTIONS, TRACE; очевидно, среди них нет ни PUT, ни DELETE, ни даже POST (администратор этого узла не сумасшедший).

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

O В этой главе:

O Краткая история создания и развития протокола CGI

O Устройство и назначение протокола CGI

O Перечень популярных CGI-переменных

Вопреки распространенному заблуждению неразрывности HTTP и CGI, последний представляет собой самостоятельный протокол, возникший еще в те незапамятные времена, когда web-серверов и в помине не существовало.

Первые, робкие попытки использования CGI-протокола HTTP-серверами относятся к 1993 году, когда возникла необходимость обрабатывать формы, заполняемые пользователем и генерировать динамические страницы, выводящие, например, результаты некоторого поиска.

Традиционный HTML этого делать не умел, о Java еще никто не слышал, поэтому единственным выходом представлялось использование для этой цели внешних программ, написанных, например, на Си и исполняющихся на сервере.

Основная проблема заключалась в стандартизации механизма взаимодействия между клиентом и удаленной программой. Интерфейс CGI занимается ничем иным, как обработкой клиентских запросов и доставкой результатов работы внешних программ.

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

Таким образом, стало возможным разрабатывать программы с использованием стандартных библиотек. Все заботы согласования с протоколом взял на себя интерфейс CGI.

Вот неполный список наиболее популярных переменных, в которых сохраняются значения некоторых полей HTTP-заголовка:

– Переменная Поле HHTP Значение

– AUTH_TYPE Authorization Механизм аутентификации

– CONTENT_LENGTH Content-Length Длина тела сообщения

– CONTENT_TYPE Content-Type Тип данных тела сообщения

– QUERY_STRING Строка параметров ресурса

– REMOTE_ADDR IP адрес клиента [276]

– REQUEST_METHOD Используемый метод (GET, POST…)

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

Именно для этого в каждый Perl-скрипт должна быть включена строка ‘print “Content-type: text/htmlnn”;’, иначе возникнет ошибочная ситуация.

Врезка «замечание»

В некоторых ситуациях, динамическая страница не генерируется, а всего лишь перенаправляется запрос на другой сервер или ресурс, изменением поля “Location:” в HTTP-заголовке.

Если результатом работы скрипта является двоичный файл солидных размеров, настоятельно рекомендуется включить в заголовок поле “Content-Length”, чтобы клиентское программное обеспечение могло корректно отображать бегунок прогресса. Сказанное выше справедливо и для обработки пользовательских запросов. Чтобы узнать длину переданных данных, скрипт должен считать переменную CONTENT_LENGTH.

Грубый пример, подпрограммы, читающей запрос пользователя, на языке Си может выглядеть так:

· fgets(*buffer,getevn(“CONTENT_LENGTH”),stdin);

Широко известный скрипт «test-cgi» [277], является не более чем тривиальным командным файлом для оболочки "sh” (UNIX), который выводит переменные окружения посредством команды «echo».

· #!/usr/bin/sh· echo Content-type: text/plain· echo· echo SERVER_SOFTWARE = $SERVER_SOFTWARE· echo SERVER_NAME = $SERVER_NAME· echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE· echo SERVER_PROTOCOL = $SERVER_PROTOCOL· echo SERVER_PORT = $SERVER_PORT· echo REQUEST_METHOD = $REQUEST_METHOD· echo HTTP_ACCEPT = "$HTTP_ACCEPT"· echo PATH_INFO = $PATH_INFO· echo PATH_TRANSLATED = $PATH_TRANSLATED· echo SCRIPT_NAME = $SCRIPT_NAME· echo QUERY_STRING = $QUERY_STRING· echo REMOTE_HOST = $REMOTE_HOST· echo REMOTE_ADDR = $REMOTE_ADDR· echo REMOTE_USER = $REMOTE_USER· echo CONTENT_TYPE = $CONTENT_TYPE· echo CONTENT_LENGTH = $CONTENT_LENGTH· SERVER_SOFTWARE = Apache/1.3.12 (Unix) mod_perl/1.22 AuthMySQL Plus/2.20.2 PHP/3.0.14 rus/PL29.4· SERVER_NAME = kpnc.softclub.net· GATEWAY_INTERFACE = CGI/1.1· SERVER_PROTOCOL = HTTP/1.1· SERVER_PORT = 80· REQUEST_METHOD = GET· HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */*· PATH_INFO =· PATH_TRANSLATED =· SCRIPT_NAME = /cgi-bin/test-cgi· QUERY_STRING = user=kpnc amp;pass=salt%20mine· REMOTE_HOST = ppp-05.krintel.ru· REMOTE_ADDR = 195.161.41.229· REMOTE_USER =· CONTENT_TYPE =· CONTENT_LENGTH =