Предложение выбора схемы идентификации

Сервер HTTP/1.1 может прислать несколько требований с откликом 401 (Authenticate), и каждое требование может использовать разную схему. Порядок присылки требований соответствует шкале предпочтений сервера. Сервер должен упорядочить требования так, чтобы наиболее безопасная схема предлагалась первой. Агент пользователя должен выбрать первую понятную ему схему.

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

Возможна атака MITM (maninthemiddle — "человек в середине"), которая заключается в добавлении слабой схемы идентификации к списку выбора в надежде на то, что клиент выберет именно ее и раскроет свой пароль. По этой причине клиент должен всегда использовать наиболее строгую схему идентификации из предлагаемого списка.

Еще эффективнее может быть MITMатака, при которой удаляется весь список предлагаемых схем идентификации и вставляется вызов, требующий базовой схемы идентификации. По этой причине агенты пользователя, обеспокоенные таким видом атак, могут запомнить самую строгую схему идентификации, которая когда­либо запрашивалась данным сервером, и выдавать предупреждение, которое потребует подтверждения пользователя при использовании более слабой схемы идентификации. Особенно хитроумным способом реализации MITM-атаки является предложение услуг свободного кэширования для доверчивых пользователей.

Злоупотребление служебными (Log) записями сервера

Сервер должен оберегать информацию о запросах пользователя, о характере его интересов (такая информация доступна в дневнике операций сервера). Эта информация является очевидно конфиденциальной по своей природе, и работа с ней во многих странах ограничена законом. Люди, использующие протокол HTTP для получения данных, являются ответственными за то, чтобы эта информация не распространялась без разрешения лиц, которых эта информация касается.

Передача конфиденциальной информации

Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных — не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации.

Четыре поля заголовка представляют интерес с точки зрения сохранения конфиденциальности: Server, Via, Referer и From.

Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией. Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall. В частности, они должны удалять или замещать любые поля Via, созданные в пределах firewall. Хотя поле Referer может быть очень полезным, его мощь может быть использована во вред, если данные о пользователе не отделены от другой информации, содержащейся в этом поле. Даже когда персональная информация удалена, поле Referer может указывать на URI частных документов, чья публикация нежелательна. Информация, посланная в поле From, может вступать в конфликт с интересами конфиденциальности пользователя или с политикой безопасности его домена, и, следовательно, она не должна пересылаться и модифицироваться без прямого разрешения пользователя. Пользователь должен быть способен установить содержимое этого поля, в противном случае оно будет установлено равным значению по умолчанию. Предлагается, хотя и не требуется, чтобы предоставлялся удобный интерфейс для пользователя, который позволяет активировать и дезактивировать посылку информации полей From и Referer.