Протокол HTTP 1.x имеет встроенный механизм
проверки правильности имени пользователя/пароля
для доступа к Web ресурсам. Этот механизм
известен как HTTP-идентификация и может быть
инициализирован или CGI сценарием, или Web
сервером непосредственно.
Имеются в настоящее время 2 режима
идентификации, встроенных в HTTP 1.1 протокол:
так называемые Основной ('Basic') и Обзорный ('Digest')
способы аутентификации.
Основная идентификация передает пару
username:password в незашифрованной форме с
браузера на сервер, и, следовательно, не
должна использоваться для важных входов в
систему, если, конечно, не используется в
зашифрованной среде типа SSL .*
Обзорная идентификация или посылает на
сервер «цифровой мусор» пары username/password, при
том шифр постоянно меняется в зависимости
от текущего времени, или снабжает сервер «солью»
(помехами в виде ошибочных элементов).
Рассмотрим эти способы:
Первый - использование «цифрового
мусора»: математическое вычисление строки
так, чтобы никакие две строки не могли иметь
одинаковое значение в этом «мусоре». Обычно
используется операция конъюнкции (логического
умножения), так, чтобы первоначальная
строка не могла быть восстановлена из
полученного мусора, единственный способ - «тупой
перебор» - сравнение известных строк со
значениями в мусоре.
Второй - использование «соли»,
значение соли - произвольная строка данных,
сгенерированная сервером для клиента.
Использование значения соли означает, что
каждая попытка идентификации с той же самой
парой username/password приведет к уникальным
значениям, и взятые из мусора данные не
могут повторно использоваться
злоумышленниками для нападения.
Механизм обзорной идентификации был
разработан для работы на незашифрованных
каналах. Пользователи должны обратить
внимание, что это не столь безопасно, как
Kerberos или механизмы идентификации на основе
секретного ключа. Также важно обратить
внимание, что только пара username:pasword защищена
этим механизмом, и в случае, когда не
используется шифрующая среда типа SSL, все
найденные документы будут доступны для
просмотра любым сторонам, имеющим доступ к
сетевому трафику.
Теперь рассмотрим основной механизм
подтверждения подлинности между клиентом (программой
просмотра) и сервером.
1) Клиент посылает стандартный HTTP запрос:
GET /download/report.doc HTTP/1.1
Accept: application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: 10.0.0.5:81
Connection: Keep-Alive
2) Сервер считывает файл конфигурации и
определяет, что ресурс находится в пределах
защищенной директории. Доступ позволен
только определенным пользователям.
3) Сервер посылает HTTP 401 - требование
подтверждения идентификации.
HTTP/1.1 401 Authorization Required
Date: Sat, 20 Oct 2001 19:28:06 GMT
Server: Apache/1.3.19 (Unix)
WWW-Authenticate: Basic realm="File Download Authorization"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
4) Браузер отображает запрос - имя
пользователя/пароль, отображая имя хоста и
опознавательную область.
5) Клиент повторно представляет запрос на
ресурс, уже с именем пользователя /паролем
GET /download/report.doc HTTP/1.1
Accept: application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: 10.0.0.5:81
Connection: Keep-Alive
Authorization: Basic ZnJlZDp0aGF0cyBtZQ==
6) Сервер сравнивает информацию клиента со
своим списком пользователей/паролей.
a) Имя пользователя/пароль допустим:
сервер посылает требуемое содержание.
b) Сбой разрешения: сервер снова посылает 401
запрос на подтверждение идентичности
c) Клиент нажимает отмену: программа
просмотра показывает сообщение об ошибке,
посланное наряду с 401 сообщением.
Из вышеупомянутого диалога обратите
внимание, что несколько специальных полей
были добавлены к различным http заголовкам. В
шаге 3, когда сервер посылает 401 ответ,
заголовок включает специальное поле:
WWW-Authenticate: Basic realm="File Download Authorization"
Значение "Basic" обозначает, что мы
просим программу просмотра использовать
основную идентификацию. Область информации
- произвольная строка, посланная, для
отображения пользователю, обычно содержит
видимое сообщение. Запрос в шаге 4
показывает HTTP диалог подтверждения
идентификации и отображается как видимая
форма. **
Пользователь заполняет форму и щелкает ok.
Программа просмотра автоматически снова
посылает запрос, как отмечено в шаге 5. Здесь
обратите внимание, что новое поле было
добавлено к стандартному запросу http:
Authorization: Basic ZnJlZDp0aGF0cyBtZQ==
Это - именно то место, где программа
просмотра посылает фактическую информацию
разрешения на сервер. Показанное поле
Authorization составлено из двух значений. Слово
Basic обозначает, что вход в систему
представляется в соответствии с основным
опознавательным методом. Блок данных,
который следует далее, является, фактически,
входом в систему, отображаемым программой
просмотра. Не позволяйте обманывать себя
тем, что данная строка, на первый взгляд,
бессмысленна и, как некоторые могут
подумать, закодирована. Это - не
подпрограмма кодировки, а просто
предоставление данных в 64-ричном формате.
Вход в систему из строки данных такого вида
может быть тривиально приведен к
текстовому виду username/password:
ZnJlZDp0aGF0cyBtZQ== -> base64Decode() -> "fred:thats me"
Процесс выполнения «обзорной»
идентификации - точно такое же, как для «основного»
опознавательного процесса, описанного выше,
различия могут возникать только в наборе
параметров, представленных браузеру, и
формате возвращенного входа в систему.
Как основной, так и обзорный способы
занимают очень важные места в комплекте
инструментов разработчиков сетевых
приложений, однако они не должны
рассматриваться, как защита высокого
качества при передаче конфиденциальной
информации или паролей, поскольку они не
защищены от нападений сетевого уровня.
Однако их многие функции остаются очень
полезными и удобными. ***
* Даже при использовании SSL
применение «основного» механизма
идентификации для конфиденциальных данных
вряд ли будет мудрым решением, если ваш
сценарий не настроен на определение, что
является http запросом, а что им не является,
иначе ваши коды входа в систему могут легко
стать жертвой небрежной (или наоборот)
написанной ссылки.
** Пользователей нужно
предостеречь при использовании просветов (Sight):
будьте внимательны перед передачей любых
авторизационных данных в систему.
Поскольку область информации связана с
произвольным удаленным сервером, она может
содержать любую информацию, даже
требование открыть свои ресурсы для
внешнего доступа.
*** Для более подробного изучения
ограничений, проблем защиты, и корректного
использования HTTP идентификации можно
просмотреть 4 раздел RFC 2617.
