Безопасность, аутентификация и целостность

Обеспечение безопасности необходимо для гарантии, что только пользователи, прошедшие аутентификацию, получат доступ к ресурсам. Сообщения, которыми обмениваются в Web, не должпы быть доступны для перехвата сторопами, не участвующими в обмене. Сообщения могут быть перехвачепы, и, следовательно, содержание сообщения должно быть недоступно для всех, кроме тех, кому оно предназначено. Рассмотрим письмо, посылаемое по почте от А к В:

•   А и В должпы быть уверены, что никто другой не прочтет содержание письма.

•   В нужен способ убедиться, что данпое письмо действительно пришло от А.

• Письмо должно быть получено В в целости и сохранности (то есть содержание, отправленное А, не должно быть изменено).

Все это относится и к НТТР-сообщениям.

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

Одним из распространенных методов аутентификации является схема запрос-ответ, в которой сервер посылает запрос и ждет специфического ответа клиента. Запрос может иметь силу только для коикретпой области (realm) — подмножества ресурсов, для которого пользователь считается аутеитифицироваипым. Эта область может отпоситься к компьютеру или набору каталогов. Каждый сервер определяет для ресурса защищенное пространство, комбинируя область ресурса и его URI. Каждое защищенное пространство имеет свою собственную базу данных авторизации. Преимущество защищенных пространств заключается в том, что к различным ресурсам могут применяться различные схемы аутентификации.

Мы пачнем с обсуждения проблем модели обеспечения безопасности НТТР/1.0 и усилий, предпринятых для их преодоления в НТТР/1.1. Затем мы рассмотрим проблемы, связанные с обеспечением целостности передаваемого содержания. Решением, принятым в НТТР/1.1, было введение аутентификациопной информации, добавляемой к сообщению или в виде заголовка, или в трейлере.

Обеспечение безопасности и аутентификация

Обеспечение безопасности становилось ключевой проблемой но мере того, как росла популярность Web и развивалась электронная коммерция. В НТТР/1.0 обеспечению безопасности уделялось минимальное внимание, была реализована схема запрос-ответ, которая позволяла клиенту получить ресурс после того, как оп подтверждал серверу, что он располагает нужными полномочиями. Это механизм обычной (basic) аутентификации, описанный в главе 6 (раздел 6.4).

Схема Обычной аутентификации в НТТР/1.0 была не слишком защищенной, так как расчет строился на том, что канал между клиентом и сервером был заслуживающим доверия. То, что это не так, было известно уже во время подготовки проекта спецификации НТТР/1.0. НТТР/1.0 не препятствовал использованию сквозного шифрования, по и не предлагал никаких других способов защиты. Имя пользователя и пароль, посылаемые клиентом запрашивающему серверу, передавались закодированными с помощью base64 [FB96a]. Кодирование base64 практически представляет собой открытый текст, имя пользователя и пароль могут стать объектом перехвата. Развитие электронной коммерции привело к передаче через Web номеров кредитных карт, которые и становятся целью перехвата.

Еще одной проблемой в НТТР/1.0 является отсутствие областей действия аутентификации. В отличие от обычной аутентификации, аутентификация с помощью дайджеста позволяет ограничить область действия аутентификации несколькими способами, включая метод запроса, URI и ограничение времени жизпи контрольных сумм. Срок действия полномочий в НТТР/1.0 был больше, чем нужно. По сути дела, полномочия были вечными. Это означает, что любой, кто перехватит идентификационные данные, может использовать их безнаказанно в течение долгого времени. Сокращение срока действия полномочий является очевидным усовершенствованием механизма безопасности. Это было реализовано в НТТР/1.1 путем ограничения ответа одним ресурсом и одним методом. Если кто-то перехватывал сообщения в сети, то он мог бы только повторить тот запрос, ответ на который оп уже зпал. От клиента требовалось вычислить контрольную сумму, включающую URI, метод запроса, имя пользователя, пароль и уникальное зпачепие временной метки. Временная метка является кодом по модулю 16 или по модулю 64, которая гарантированно является уникальной для каждого момента, когда сервер посылает ответ 401 Unauthorized (ответ 401 Unauthorized посылается тогда, когда сервер считает, что нолпомочия клиента являются недостаточными). Значение временной метки создается на основе комбинации времени, генерируемого сервером, атрибута доступа к содержимому ресурса и личного ключа, известного только серверу. Временная метка для клиента непрозрачна.

Аутентификация в HTTP подробно обсуждается в документе RFC 2617, который является документом, сопутствующим спецификации НТТР/1.1 (RFC 2616).

Целостность

Целостность сообщения — это важная составная часть обеспечения безопасности: то, что было отправлено, должно быть доставлено получателю в целости и сохранности. Новый заголовок содержимого Content-MD5 в НТТР/1.1 используется для проверки целостности тела содержимого. Дайджест MD5 является 128-разряд- пой коитролыюй суммой и представляется в HTTP в виде 32-х отображаемых символов ASCII. Биты преобразуются от старших к младшим, группами по четыре бита в шестпадцатеричные цифры от 0 до f (например, битовая строка 1010 представляется шестпадцагеричной цифрой а, а 0100 — шестпадцатеричпой цифрой 4). Дайджест позволяет получателю убедиться, что полученное содержание является точно тем же, которое было отправлено. Заголовок Content-MD5 могут использовать только исходные серверы, поскольку он предназначен для реализации сквозного контроля целостности. Однако все промежуточные серверы (например, прокси-серверы и шлюзы) могут проверять целостность полученной ими информации.

Распространенной в Internet угрозой является атака отказа от обслуживания (DoS — Denial of Service). В Web DoS-атака может принимать множество форм, включая передачу Web-серверу сообщений большого объема. Сообщения большого объема могут переполнить буферы и также привести к нарушению безопасности. DoS -атака — это классическая проблема, с которой сталкиваются серверы; если бы серверу была известпа длина сообщения а priori, сервер мог бы принять Решение о том, следует ли ему расходовать свои ресурсы на обработку запроса. Код ответа 411 Length Required дает клиенту попять, что серверу необходимо зпать длину тела содержимого сообщения до обработки запроса. Это стандартный способ гарантировать, что протокол не заставит сервер принимать сообщения произвольно большого объема. Однако если сообщение разбито на фрагменты (см. раздел 7.6), то можно не указывать длину содержимого в сообщении. Сервер, поддерживающий НТТР/1.1, обязан анализировать сообщения разбитые на фрагменты. Однако сервер в любой момепт может принять решение, что сообщение слишком велико и отправить код ответа 411 Length Required и затем закрыть соединение.

Новый код ответа 414 Request-URI Too Long может быть возвращен, если сервер не готов обрабатывать слишком длинный URI. Поскольку в протоколе максимальная длина не определена, конкретные реализации пользуются своими собственными ограничениями, чтобы установить соответствующее зпачепие. Хороший способ применения данного кода состояния, это когда сервер полагает, что производится атака типа переполнения буфера. Программы, которые имеют фиксиро- ванные строковые буферы и не отслеживают переполнение, могут допустить перезапись других разделов программного кода, что может привести к нарушению безопасности.

Обеспечению безопасности в НТТР/1.1 уделепо серьезное впимапие: предотвращается передача паролей открытым текстом, ограпичеп срок действия полномочий и введепы средства, помогающие сохранить целостность сообщений. Были созданы новые коды ответов, чтобы предоставить реализациям компонентов возможность узнавать о попытках нарушения безопасности.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100