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

·

Ознакомившись с ответом сервера, мысленно поблагодарим разработчиков за разъяснение причин отказа в обслуживании. Открыв секцию 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-серверам внутренние ссылки от внешних, оптимизируя сетевой трафик.

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

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

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

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

Например:

В приведенном примере сервером сообщается установленное на нем программное обеспечение (вплоть до версии реализации) и разрешенные методы - 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/html\n\n”;’, иначе возникнет ошибочная ситуация.

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

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

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

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

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