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

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

Выделенная жирным шрифтом строка «Connection: close» говорит о том, что по умолчанию выбран режим разрыва соединения сразу же после выдачи ответа. Такой поход снижает нагрузку на сервер, позволяя пользователю спокойно, не торопясь изучать содержимое странички, не занимая канал. Однако, это не совсем удобно (или совсем неудобно) при работе в telnet-клиенте.

Чтобы изменить значение поля “Connection” на противоположное, необходимо присвоить ему значение «Keep-Alive», послав серверу любой запрос [254]. Один из способов сделать это, продемонстрирован ниже:

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

Манипулируя значением “timeout” можно увеличить этот промежуток до 100 секунд (вполне достаточно для комфортной работы в telnet-клиенте), но это предел, превысить который не позволят настойки сервера. (Максимальное ограничение во времени на удержание соединения варьируется от сервера к серверу).

Остальные поля заголовка исчерпывающе описаны в RFC-1945 и RFC-2068, и здесь не рассматриваются.

Для удаленного выполнения программ может использоваться все тот же метод “GET”, вызываемый точно так, как для запроса содержимого обычного HTML-документа. Единственное различие заключается в том, что клиенту возвращается не исходный текст программы, а результат ее работы. Получить в свое распоряжение содержимое исполняемого файла невозможно (точнее не должно быть возможно), даже если имеются права на его чтение.

Вспоминается громкий скандал, развернувшийся вокруг обнаруженной ошибки в Internet Information Server 3.0 (IIS 3.0), позволяющий получить доступ к содержимому asp (Active Server Pages) скриптов добавлением в конце имени знака точки. То есть, если к default.asp [255], расположенному на сайте www.microsoft.com [256], обратиться так - “ GET / default. asp . [257] ”,то сервер вернет сам файл, а не результат его работы.

Например:

GET /Default.asp.

«% emailx=request.form("email")

remarkx=request.form("remark")

Set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open "Local SQL Server", "sa", "DTide"

Set RS = Conn.Execute("insert into Web_data.dbo.ASP_data(email,remark) values('" amp; emailx amp; "','" amp; remarkx amp; "')") %»

Your information has been added to our database.

Разработчики впопыхах дописали несколько наивных строк тривиально фильтра и поплатились за это. В суматохе никому и в голову не пришло, что тот же самый вызов можно записать и как - “GET /default.asp %20/”, то есть заменить символ точки ее шестнадцатеричным значением. И только что выпущенная заплатка оказалась бесполезной.

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

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

В качестве небольшого упражнения, можно запустить демонстрационный пример, расположенный по адресу http://lighning.prohosting.com/~/kpnc/cgi-bin/helo.plРезультат его работы показан на рисунке, приведенном ниже:

Если заглянуть в исходный файл, прилагаемый к книге (“/SRC/Hello.pl”), бросается в глаза одна странность:

· #!/usr/local/bin/perl -w

· print " Content-type: text/html\n\n";

· print "Hello,Sailor!\n";

Сервер «съел» одну строку (в листинге она выделена жирным шрифтом). Если же ее попытаться убрать, то выполнение скрипта прервется с сообщением об ошибке. Причины такого поведения подробно рассмотрены в дополнении «Протокол CGI».