Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК
«The most serious flaw in Basic authentication is that it results in the essentially clear text transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
Because Basic authentication involves the clear text transmission of passwords it SHOULD never be used (without enhancements) to protect sensitive or valuable information.»
RFC-2068, раздел 15.1, страница 140.
Врезка «алгоритм кодировки base64»
Битовый поток разбивается на двадцати четырех битовые сегменты, делящиеся на четыре части по 6 бит (26 - 64, отсюда и название), каждая из которых содержит один символ, кодируемый в соответствии с особой таблицей, состоящей из читабельных кодов ASCII.
Выполнить вручную перекодировку строки пароля в base64-формат довольно-таки затруднительно, но у пользователей Windows всегда под рукой средство, автоматизирующее эту задачу. Речь идет о приложении “Outlook Express”. Достаточно настроить его надлежащим образом (в меню «Сервис» выбрать пункт «Параметры», перейти к закладке «Отправка сообщений» кликнуть по кнопке «Настойка текста»; в открывшемся диалоговом окне установить кодировку Base64) и послать письмо самому себе - оно будет автоматически перекодировано.
Рисунок 23 Настойка Outlock Express для пересылки писем в кодировке Base64
При этом строка “KPNC:MyGoodPassword” [264] будет выглядеть следующим образом (в меню «Файл» выбрать «Свойства», перейти к закладке «Подробности», кликнуть по кнопке «Исходный текст сообщения»):
· S1BOQzpNeUdvb2RQYXNzd29yZ
Полный заголовок запроса для доступа к главной странице сервера может выглядеть, например, так:
· GET / HTTP/1.0
· Authorization: Basic S1BOQzpNeUdvb2RQYXNzd29yZ
Если пароль введен правильно, то сервер вернет запрошенный ресурс. В противном случае появится сообщение об ошибке.
Врезка «замечание»
В Internet-магазинах и аналогичных системах, предъявляющих повышенное требование к безопасности, широко используется шифрование данных на уровне транспортного протокола TCP.
Популярный механизм SSL (Secure Sockets Layer) представляет собой самостоятельный протокол, применяющийся для передачи зашифрованного пароля и пользовательских данных, поверх которого могут работать как HTTP, так FTP, SMTP и другие протоколы.
Реализации SSL поддерживают множество криптоалгоритмов, таких как RSA, DES, MD5, выбираемых в зависимости от ценности и рода передаваемой информации. К сожалению, ранние версии ограничивались ключами небольшой длины, но с развитием Internet - торговли это было исправлено [265].
Изучение протокола SSL и методов криптоанализа выходит за рамки данной книги. Интересующиеся этим вопросом могут обратиться к домашней станице Павла Семьянова (http://www.ssl.stu.neva.ru/psw/), посвященной криптографии и ее безопасности.
Метод POST, аналогично PUT, предназначен для передачи данных от клиента на сервер. Однако они не сохраняются в виде файла, а передаются скрипту параметрами командой строки. С первого взгляда непонятно, какими соображениями руководствовались разработчики при введении нового метода. Ведь с этой задачей неплохо справляется и GET! Пример, приведенный ниже, доказывает справедливость такого утверждения:
· «BODY»
· «A HREF=”lightning.prohosting.com/~kpnc/cgi-bin/post.pl?user=kpnc amp;pass=saltmine”»
· Click«/A»
· «/BODY»
Рисунок 024 показывает, что параметры, передаваемые скрипту методом GET, отображаются в адресной строке браузера и доступны для изучения всем желающим. А это нехорошо с точки зрения политики безопасности.
Рисунок 024 Передача параметров методом GET
Результат работы POST незаметен для пользователя, поэтому он хорошо справляется с передачей конфиденциальных данных. Но прежде чем продолжить повествование, необходимо ознакомиться формой представления параметров.
Строго говоря, способ представления и отделения параметров друг от друга может варьироваться от разработчика к разработчику. Строка, переданная скрипту, независимо от формы записи, может быть целиком получена с помощью функции ARGV, и в этом смысле она ничем не отличается от привычной командной строки консольных приложений для MS-DOS и Windows. Тем не менее, разработчики стараются придерживаться определенных соглашений. Обычно строка параметров представляет собой совокупность лексем, разделенных символами “ amp;”. Каждая лексема состоит из имени параметра и его значения, разделенных знаком равенства. Все нечитабельные символы заменяются знаком “%” и последующим за ним шестнадцатеричным значением символа. От имени ресурса строка параметров отделяется вопросительным знаком. Сказанное поясняет следующий пример:
· lightning.prohosting.com/~kpnc/cgi-bin/post.pl?user=kpnc amp;pass=saltmine
Все, находящееся слева вопросительного знака, то есть “lightning.prohosting.com/~kpnc/cgi/-bin/post.pl” называется именем ресурса (сокращенно URL или URN - Uniform Resource Name). URL состоит из имени хоста (в даннос случае “lightning.prohosting.com”), пути (“/~kpnc/cgi-bin/”) и имени файла (“post.pl”).
За именем файла следует строка параметров, образованная из двух лексем - “user=kpnc” и “pass=saltmine”. Порядок лексем не играет никакой роли, и скрипт будет работать ничуть не хуже, если их поменять местами.
Каждая лексема состоит из имени параметра («user», «pass») и его значения («kpnc» и «saltmine» соответственно). Символ пробела в значениях параметра недопустим, поэтому, если потребовалось бы «saltmine» написать раздельно [266], то это выглядело бы так “salt%20mine”.
Врезка «информация»
Любопытная особенность связана с возможностью записи одного и того же IP-адреса огромным множеством способов. Например, его можно представить в шестнадцатеричном виде, воспользовавшись префиксом ‘0x’, тогда «209.90.125.196» (адрес узла lightning.prohosting.com) будет выглядеть как «0xD1.0x5A.0x7D.0xC4» [267]. Если число начинается с нуля, то оно трактуется как восьмеричное, и тот же адрес может быть записан как «0321.0132.0175.0304». Наконец, символ ‘b’ в окончании числа указывает на двоичную форму записи [268].
Очевидно, описанные выше способы можно комбинировать друг с другом, получая в результате этого, например, «0xD1.0132.125.0xC4» (первое и последние числа шестнадцатеричные, второе слева восьмеричное, и оставшееся - десятичное).
Вообще же, с точки зрения операционной системы любой IP-адрес это одно 32-битное целое, поэтому некоторые приложения [269] позволяют опустить точку-разделитель. Однако для этого необходимо предварительно перевести адрес в шестнадцатеричную форму записи. Это легко понять, так как «0xD1.0x5A.0x7D.0xC4» и «0xD15A7DC4» взаимно эквиваленты между собой. Но ничто не мешает полученный результат перевести в любую другую, например десятичную («3512368580») или восьмеричную («032126476704») нотацию [270].
Кроме этого, допустимо вместо символа использовать его ASCII-код, предваренный знаком процента. Так, например, выражение «%32%30%39%2E%39%30%2E%31%32%35%2E%31%39%36» эквивалентно адресу «209.90.125.196»!
Но пользоваться этими хитрыми приемами, необходимо с большой осторожностью - нет никакой гарантии, что используемое клиентом программное обеспечение будет их поддерживать. Тем более не стоит оформлять таким способом ссылки на общедоступных страничках, - ведь не известно, чем воспользуется посетитель для их просмотра.
В некоторых публикациях таким способом предлагается скрывать реальный IP-адрес сайта противозаконной тематики от работников спецслужб. Представляется сомнительным, существование в органах специалистов с квалификацией, недостаточной для решения даже такой простой задачи.
Врезка «информация»
Одним из способов аутентификации может быть передача имени пользователя и пароля в строке запроса следующим образом: http://user: [email protected]/path/file
К ее недостаткам можно отнести открытую передачу пароля и его незащищенность от постороннего глаза. Поэтому такой способ в настоящее время практически вышел из употребления.
Очевидно, следует избегать появления пароля в адресной строке браузера. С этой точки зрения очень удобен метод POST, передающий значения всех параметров в теле запроса. Однако, скрипту, анализирующему данные, совершенно все равно, каким способом те были посланы - он не отличает POST от GET. Пример, приведенный ниже, доказывает это утверждение:
· GET /~kpnc/cgi-bin/post.pl?user=kpnc amp;pass=saltmine HTTP/1.0
·
· HTTP/1.1 200 OK
· Date: Sun, 16 Apr 2000 17:01:10 GMT
· Server: Apache/1.3.6 (Unix)
· Connection: close
· Content-Type: text/html
·
· «H1»«CENTER»Simple POST Sample«/CENTER»
· «HR»USER:«I»kpnc
· «BR»PASS:«I»saltmine
· POST /~kpnc/cgi-bin/post.pl HTTP/1.0
· Content-length:25
·
· user=kpnc
· amp; pass=saltmine
·
· HTTP/1.1 200 OK
· Date: Sun, 16 Apr 2000 17:00:34 GMT
· Server: Apache/1.3.6 (Unix)
· Connection: close
· Content-Type: text/html
·
· «H1»«CENTER»Simple POST Sample«/CENTER»
· «HR»USER:«I»kpnc
· «BR»PASS:«I»saltmine
Идентичность ответов сервера доказывает, что независимо от способа передачи параметров, удаленная программа работает одинаково. Причем, перенос строки в методе POST не способен отделить один параметр от другого и если символ-разделитель « amp;» опустить, будет обработана только одна лексема - “user=kpnc”.
