Гипертекстный протокол HTTP

Поле Max-Forwards

Поле заголовка запроса Max-Forwards может использоваться с методом TRACE, чтобы ограничить число прокси или шлюзов, которые могут переадресовывать запрос. Это полезно, когда клиент пытается отследить путь запроса в случае возникновения различных проблем.

Max-Forwards = "Max-Forwards" ":" 1*DIGIT

Значение Max-Forwards представляет собой целое десятичное число, которое указывает, сколько еще раз запрос можно переадресовать.

Каждый прокси или шлюз получатель запроса TRACE, содержащего поле заголовка Max-Forwards, должен проверить и актуализовать его величину прежде, чем переадресовывать запрос. Если полученная величина равна нулю, получателю не следует переадресовывать запрос. Вместо этого ему следует откликнуться как конечному получателю статусным кодом 200 (OK), содержащим полученное сообщение­запрос в качестве тела отклика. Если полученное значение больше нуля, то переадресованное сообщение должно содержать актуализованное значение поля Max-Forwards (уменьшенное на единицу).

Поле заголовка Max-Forwards следует игнорировать для всех других методов, определенных в данной спецификации, и для всех расширений методов, для которых это не является частью определения метода.

Поле Pragma

Поле общего заголовка Pragma используется для включения специальных директив (зависящих от конкретной реализации), которые могут быть применены ко всем получателям вдоль цепочки запрос/отклик. Все директивы pragma специфицируют с точки зрения протокола опционное поведение. Однако некоторые системы могут требовать, чтобы поведение соответствовало директивам:

Pragma      = "Pragma" ":" 1#pragmadirective
pragmadirective  = "no-cache" | extensionpragma
extensionpragma  = token [ "=" ( token | quotedstring ) ]

Когда в запросе присутствует директива nocashe, приложение должно переадресовать запрос исходному серверу, даже если имеется кэшированная копия того, что запрошено. Директива pragma имеет ту же семантику, что и директива кэша no-cache, и определена здесь для обратной совместимости с HTTP/1.0. Клиентам следует включать в запрос оба заголовка, когда посылается запрос no-cache серверу, о котором не известно, совместим ли он с HTTP/1.1.

Нельзя специфицировать директиву pragma для какогото отдельного получателя. Однако любая директива pragma, неприемлемая для получателя, должна им игнорироваться.

Клиенты HTTP/1.1 не должны посылать заголовок запроса Pragma. Кэши HTTP/1.1 должны воспринимать "Pragma: no-cache", как если бы клиент послал "Cache-Control: no-cache".

Поле Proxy-Authenticate

Поле заголовка отклика Proxy-Authenticate должно быть включено в качестве части отклика 407 (Proxy Authentication Required). Значение поля состоит из вызова, который указывает схему идентификации, и параметров, применимых в прокси для данного Request-URI.

Proxy-Authenticate = "Proxy-Authenticate" ":" challenge

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

Поле Proxy-Authorization

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

Proxy-Authorization = "Proxy-Authorization" ":" credentials

В отличие от Authorization, поле заголовка Proxy-Authorization применимо только к следующему внешнему прокси, который требует авторизации с помощью поля Proxy-Authenticate. Когда работает несколько прокси, объединенных в цепочку, поле заголовка Proxy-Authorization используется первым внешним прокси, который предполагает получение авторизационных параметров. Прокси может передать эти параметры из запроса клиента следующему прокси, если существует механизм совместной авторизации при обслуживании данного запроса.

Поле Public

Поле заголовка отклика Public содержит список методов, поддерживаемых сервером. Задачей этого поля является информирование получателя о возможностях сервера в отношении необычных методов. Перечисленные методы могут быть, а могут и не быть применимыми к Request-URI. Поле заголовка Allow служит для указания методов, разрешенных для данного URI.

Public  = "Public" ":" 1#method

Пример использования:

Public: OPTIONS, MGET, MHEAD, GET, HEAD

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

Фрагмент. Фрагменты байт

Так как все объекты HTTP в процессе передачи представляют собой последовательности байт, концепция фрагментов является существенной для любого объекта HTTP. Однако не все клиенты и серверы нуждаются в поддержке операций с фрагментами.

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

Операция с байтовыми фрагментами может относиться к одному набору байт или к нескольким таким наборам в пределах одного объекта.

rangesspecifier    = byterangesspecifier
byterangesspecifier  = bytesunit "=" byterangeset
byterangeset    = 1#( byterangespec | suffixbyterangespec )
byterangespec    = firstbytepos "" [lastbytepos]
firstbytepos    = 1*DIGIT
lastbytepos      = 1*DIGIT

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

Если присутствует значение lastbytepos, оно должно быть больше или равно значению firstbytepos в спецификации byterangespec, в противном случае спецификация byterangespec не корректна. Получатель некорректной спецификации byterangespec должен ее игнорировать.

Если значение lastbytepos отсутствует или если значение больше или равно текущей длине тела объекта, значение lastbytepos берется на единицу меньше текущего значения длины тела объекта в байтах.

При выборе lastbytepos клиент может ограничить число копируемых байт, если не известна длина объекта.

suffixbyterangespec = "" suffixlength
suffixlength = 1*DIGIT

Спецификация suffixbyterangespec применяется для задания суффикса тела объекта с длиной, заданной значением suffixlength. То есть, эта форма специфицирует последние N байтов тела объекта. Если объект короче заданной длины суффикса, то в качестве суффикса используется все тело объекта.

Примеры значений byterangesspecifier (предполагается, что длина тела объекта равна 10000):

• Первые 500 байтов (относительные позиции 0-499, включительно): bytes=0-499
• Вторые 500 байтов (относительные позиции 500-999, включительно): bytes=50-0999
• Последние 500 байтов (относительные позиции 9500-9999, включительно): bytes=500 или bytes=9500
• Первые и последние байты (байты 0 и 9999): bytes=0-0,1
• Несколько легальных, но неканонических спецификаций вторых 500 байт (относительные позиции 500999, включительно): bytes=500-600,601-999; bytes=500-700,601-999

Запросы получения фрагментов

Информационные запросы HTTP, использующие условные или безусловные методы GET, могут заказывать один или более субфрагментов объекта, а не целый объект, применяя заголовок запроса Range:

Range  = "Range" ":" rangesspecifier

Сервер может игнорировать заголовок Range. Однако исходные серверы HTTP/1.1 и промежуточные кэши должны поддерживать по возможности работу с фрагментами, так как Range поддерживает эффективное восстановление в случае частично неудачных пересылок больших объектов.

Если сервер поддерживает заголовки Range и специфицированный фрагмент или фрагменты подходят для данного объекта, то:

• присутствие заголовка Range в безусловном GET допускает модификацию того, что прислано. Другими словами отклик может содержать статусный код 206 (Partial Content) вместо 200 (OK);
• присутствие заголовка Range в условном GET (запрос использует If-Modified-Since, If-None-Match, If-Unmodified-Since и/или If-Match ) модифицирует то, что прислано GET в случае успешного завершения при выполнении условия ( TRUE ). Это не влияет на отклик 304 (Not Modified), если условие не выполнено ( FALSE ).

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

Поле Referer

Поле заголовка запроса Referer позволяет клиенту специфицировать (для пользы сервера) адрес (URI) ресурса, из которого был получен Request-URI. Заголовок запроса Referer дает возможность серверу генерировать список обратных связей с ресурсами для интереса, ведения дневника, оптимизации кэширования и т.д.. Он позволяет также заставить работать устаревшие или дефектные связи. Поле Referer не должно посылаться, если Request-URI был получен от источника, который не имеет своего собственного URI, такого, например, как ввод с пользовательского терминала.

Referer  = "Referer" ":" ( absoluteURI | relativeURI )

Пример:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

Если значением поля является частичный URI, его следует интерпретировать относительно Request-URI. URI не должен включать фрагментов.

Замечание. Так как первоисточник связи может быть конфиденциальной информацией или может раскрывать другой источник частной информации, настоятельно рекомендуется, чтобы пользователь имел возможность решать, посылать поле Referer или нет. Например, клиент-броузер может иметь кнопку-переключатель для открытого или анонимного просмотра, которая управляет активацией/дезактивацией посылки информации Referer и From.

Поле Retry-After

Поле заголовка отклика Retry-After может использоваться с кодом статуса 503 (Service Unavailable), чтобы указать, как долго еще данная услуга предполагается недоступной для запрашивающего клиента. Значением этого поля может быть либо дата http, либо целое число секунд (в десятичном исчислении) после отправки отклика.

Retry-After  = "Retry-After" ":" ( HTTPdate | deltaseconds )

Два примера использования поля:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

В последнем примере задержка равна двум минутам.

Поле Server

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

Server  = "Server" ":" 1*( product | comment )

Например:

Server: CERN/3.0 libwww/2.17

Если отклик переадресуется через прокси, приложение прокси не должно модифицировать заголовок отклика сервера. Вместо этого ему следует включить в отклик поле Via.

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

Поле Transfer-Encoding (Транспортное кодирование)

Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования (если таковое использовано) применен к телу сообщения, чтобы безопасно осуществить передачу между отправителем и получателем. Это поле отличается от Content-Encoding тем, что транспортное кодирование является параметром сообщения, а не объекта.

Transfer-Encoding = "Transfer-Encoding" ":" 1#transfercoding

Например:

Transfer-Encoding: chunked

Многие старые приложения HTTP/1.0 не воспринимают заголовок Transfer-Encoding.

Заголовок Upgrade (Актуализация)

Общий заголовок Upgrade позволяет клиенту специфицировать, какие дополнительные коммуникационные протоколы он поддерживает и хотел бы использовать, если сервер найдет их подходящими. Сервер должен применять поле заголовка Upgrade в отклике 101 (Switching Protocols) для указания, какие протоколы активны.

Upgrade  = "Upgrade" ":" 1#product

Например:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода от протокола HTTP/1.1 к некоторым другим. Клиенту разрешается объявлять о намерении использовать другой протокол, например, более позднюю версию HTTP с большим старшим кодом версии, даже если текущий запрос выполнен с использованием HTTP/1.1. Это облегчает переходы между несовместимыми протоколами за счет разрешения клиенту инициировать запрос в более широко поддерживаемом протоколе, и в то же время, указывая серверу, что он предпочел бы использовать протокол получше, если таковой доступен (где понятие "получше" определяется сервером, возможно, согласно природы метода и/или запрашиваемого ресурса).

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

Поле Upgrade применимо только к текущему соединению. Следовательно, ключевое слово upgrade должно содержаться в поле заголовка Connection всякий раз, когда поле Upgrade присутствует в сообщении HTTP/1.1.

Поле заголовка Upgrade не может использоваться для указания смены протокола в другом соединении. Для этой цели более приемлемы отклики переадресации с кодами 301, 302, 303 или 305.

Данная спецификация определяет протокол с именем HTTP при работе с семейством протоколов для передачи гипертекста (Hypertext Transfer Protocols), как это определено в правилах работы с версиями HTTP и для будущих усовершенствований этой спецификации.

Поле User-Agent (Агент пользователя)

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

User-Agent  = "User-Agent" ":" 1*( product | comment )

Например:

User-Agent: CERNLineMode/2.15 libwww/2.17b3

Поле Vary

Поле заголовка отклика Vary используется сервером, чтобы сигнализировать о том, что отклик выбран из числа имеющихся представлений с помощью механизма согласования под управлением сервера. Значение поля Vary указывает на то, что данный набор полей заголовка ограничивает пределы, в которых могут варьироваться представления, или что пределы вариации не специфицированы ("*") и, таким образом, могут модифицироваться в широких пределах для будущих запросов.

Vary  = "Vary" ":" ( "*" | 1#fieldname )

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

Набор полей заголовка, перечисленных в поле Vary, известен как выбирающие заголовки запроса.

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

Сортирующие заголовки от двух запросов считаются соответствующими тогда и только тогда, когда сортирующие заголовки первого запроса могут быть преобразованы в сортирующие заголовки второго запроса с помощью добавления или удаления строчных пробелов LWS (Linear White Space) в местах, где это допускается соответствующими правилами BNF (BackusNaur Form), и/или комбинируя несколько полей заголовка.

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

Значение поля Vary, состоящее из списка имен полей, сигнализирует о том, что представление, выбранное для отклика, базируется на алгоритме выбора, который рассматривает только значения, перечисленные в поле заголовка запроса. Кэш может предполагать, что тот же выбор будет сделан для будущих запросов с теми же значениями имен полей, для периода времени, в течение которого отклик остается свежим.

Имена полей не ограничены набором стандартных полей заголовков запросов, определенных в данной спецификации. Имена полей могут быть записаны строчными или прописными буквами.

Поле Via

Поле общего заголовка Via должно быть использовано шлюзами или прокси для указания промежуточных протоколов и получателей на пути от агента пользователя к серверу, которому адресован запрос, и между исходным сервером и клиентом в случае отклика. Оно аналогично полю Received документа RFC-822 и предназначено для использования при трассировке переадресаций сообщений, исключения петель запроса и идентификации протокольных возможностей всех отправителей вдоль цепочки запрос/отклик.

Via          = "Via" ":" 1#( receivedprotocol receivedby [ comment ] )
receivedprotocol  = [ protocolname "/" ] protocolversion
protocolname      = token
protocolversion      = token
receivedby      = ( host [ ":" port ] ) | pseudonym
Pseudonym      = token

Запись receivedprotocol указывает версию протокола в сообщении, полученном сервером или клиентом вдоль цепочки запрос/отклик. Версия receivedprotocol добавляется к значению поля Via, когда сообщение переадресуется, так что информация о возможностях протоколов предыдущих приложений остается прозрачной для всех получателей.

Запись protocolname является опционной тогда и только тогда, когда это протокол HTTP. Поле receivedby обычно соответствует ЭВМ и номеру порта сервера получателя или клиента, который переадресует сообщение. Однако если настоящее имя ЭВМ считается конфиденциальной информацией, оно может быть заменено псевдонимом. Если номер порта не задан, можно предполагать, что используется значение по умолчанию для данного протокола ( receivedprotocol ).

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

Комментарии могут быть использованы в поле заголовка Via для идентификации программ получателя прокси или шлюза аналогично полям User-Agent и Server header. Однако все комментарии в поле Via являются опционными и могут быть удалены любым получателем перед тем, как переадресовать сообщение.

Например, сообщение­запрос может быть послано от агента пользователя HTTP/1.0 программе внутреннего прокси с именем fred — она применяет HTTP/1.1 для того, чтобы переадресовать запрос общедоступному прокси с именем nowhere.com, который завершает процесс переадресации запроса исходному серверу www.ics.uci.edu. Запрос, полученный www.ics.uci.edu, будет тогда иметь следующее поле заголовка Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Прокси и шлюзы, используемые как средства сетевой защиты (firewall) не должны по умолчанию переадресовывать имена ЭВМ и портов в пределах области firewall. Эта информация может передаваться, если это позволено непосредственно. Если это не разрешено, запись receivedby для ЭВМ в зоне действия firewall должна быть заменена соответствующим псевдонимом.

Для организаций, которые имеют жесткие требования к защите конфиденциальности и сокрытию внутренней структуры, прокси может комбинировать субпоследовательность поля заголовка Via с идентичными значениями receivedprotocol в единую запись. Например,

Via: 1.0 vanya, 1.1 manya, 1.1 dunya, 1.0 sonya

Приложениям не следует комбинировать несколько записей, если они только не находятся под единым административным контролем и имена ЭВМ уже заменены на псевдонимы. Приложения не должны комбинировать записи, которые имеют различные значения receivedprotocol.

Поле Warning (Предупреждение)

Поле заголовка отклика Warning используется для переноса дополнительной информации о состоянии отклика, которая может отражать статусный код. Эта информация обычно служит для предупреждения о возможной потере семантической прозрачности изза операций кэширования. Заголовки Warning посылаются с откликами, применяя:

Warning      = "Warning" ":" 1#warningvalue
warningvalue  = warncode SP warnagent SP warntext
warncode    = 2DIGIT
warnagent    = ( host [ ":" port ] ) | pseudonym
; имя или псевдоним сервера, добавившего заголовок Warning,
; предназначенный для целей отладки 
warntext    = quotedstring

Отклик может нести в себе более одного заголовка Warning.

Запись warntext производится на естественном языке и с применением символьного набора, приемлемого для принимающего отклик лица. Это решение может базироваться на некоей имеющейся информации, такой, как положение кэша или пользователя, поле запроса AcceptLanguage, поле отклика ContentLanguage и т.д. Языком по умолчанию является английский, а символьным набором — ISO88591.

Если используется символьный набор, отличный от ISO88591, он должен быть закодирован в warntext с использованием метода, описанного в RFC-1522 [7.14].

Любой сервер или кэш может добавить заголовки Warning к отклику. Новые заголовки Warning должны добавляться после любых существующих заголовков Warning. Кэш не должен уничтожать какие-­либо заголовки, которые он получил в отклике. Однако если кэш успешно перепроверил запись, ему следует удалить все заголовки Warning, присоединенные ранее, за исключением специальных кодов Warning. Он должен добавить к записи новые заголовки Warning, полученные с откликом перепроверки. Другими словами, заголовками Warning являются те, которые были бы получены в отклике на запрос в данный момент.

Когда к отклику подключено несколько заголовков Warning, агенту пользователя следует отображать их столько, сколько возможно, для того чтобы они появились в отклике. Если невозможно отобразить все предупреждения, агент пользователя должен следовать следующим эвристическим правилам.

• Предупреждения, которые появляются в отклике раньше, имеют приоритет перед теми, что появляются позже.
• Предупреждения с предпочитаемым пользователем символьным набором имеют приоритет перед предупреждениями с другими, но идентичными warncodes и warnagents наборами.

Системы, которые генерируют несколько заголовков Warning, должны упорядочить их с учетом ожидаемого поведения агента пользователя.

Далее представлен список определенных в настоящее время кодов предупреждений, каждый из которых сопровождается рекомендуемым текстом на английском языке и описанием его значения.

10 Response is stale (отклик устарел)

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

11 Revalidation failed (перепроверка пригодности неудачна)

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

12 Disconnected operation (работа в отключенном от сети состоянии)

Следует включать, если кэш намерено отключен от остальной сети на определенный период времени.

13 Heuristic expiration (эвристическое определение времени пригодности)

Должно включаться, если кэш эвристически выбрал время жизни больше 24 часов, а возраст отклика превышает эту величину.

14 Transformation applied (применено преобразование)

Должно добавляться промежуточным кэшем или прокси, если он использует какое­либо преобразование, изменяющее кодировку содержимого (как это специфицировано в заголовке Content-Encoding ) или тип среды (как это описано в заголовке Content-Type ) отклика, если только этот код предупреждения не присутствует уже в отклике.

99 Разные предупреждения

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

Поле WWW-Authenticate

Поле заголовка отклика WWW-Authenticate должно включаться в сообщения откликов со статусным кодом 401 (Unauthorized). Значение поля содержит, по крайней мере, одно требование, которое указывает на схему идентификации и на параметры, применимые для Request-URI.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

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

Соображения безопасности

Этот раздел предназначен для того, чтобы проинформировать разработчиков приложений, поставщиков информации и пользователей об ограничениях безопасности в HTTP/1.1.

Аутентификация клиентов

Базовая схема не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и каких-­либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей).

Наиболее серьезным дефектом базового механизма идентификации в HTTP является то, что пароль пользователя передается по сети в незашифрованном виде.

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

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

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

Базовая идентификация уязвима также для атак поддельных серверов. Когда пользователь связывается с ЭВМ, которая содержит информацию, защищенную с использованием базовой системой идентификации, может оказаться, что в действительности он соединяется с серверомзлоумышленником, целью которого является получение идентификационных параметров пользователя (например, имени и пароля). Этот тип атак невозможен при использовании идентификации с помощью дайджестов [7.32]. Разработчики серверов должны учитывать возможности такого рода атак со стороны ложных серверов или CGIскриптов. В частности, очень опасно для сервера просто прерывать связь со шлюзом, так как этот шлюз может тогда использовать механизм постоянного соединения для выполнения нескольких процедур с клиентом, исполняя роль исходного сервера не заметно для клиента.

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

Сервер 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.

Атаки, основанные на именах файлов и проходах

Реализация исходных серверов HTTP должна быть тщательной, чтобы ограничить список присылаемых HTTP документов теми, которые определены для этого администратором сервера. Если сервер HTTP транслирует HTTP URI непосредственно в запросы к файловой системе, сервер должен следить за тем, чтобы не пересылать клиентам HTTP файлы, для этого не предназначенные. Например, UNIX, Microsoft Windows и другие операционные системы используют ".." как компоненту прохода, чтобы указать уровень каталога выше текущего. В такой системе сервер HTTP должен запретить любую подобную конструкцию в Request-URI, если она позволяет доступ к ресурсу за пределами того, что предполагалось. Аналогично, файлы, предназначенные только для внутреннего использования сервером (такие, как файлы управления доступом, конфигурационные файлы и коды скриптов), должны быть защищены от несанкционированного доступа, поскольку они могут содержать конфиденциальную информацию. Практика показала, что даже незначительные ошибки в реализации сервера HTTP могут привести к рискам безопасности.

Персональная информация

Клиентам HTTP небезразличен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Настоятельно рекомендуется создавать удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации.

Аспекты конфиденциальности, связанные с заголовками Accept

Заголовок запроса Accept может раскрыть информацию о пользователе всем серверам, к которым имеется доступ. В частности, заголовок AcceptLanguage может раскрыть информацию, которую пользователь, возможно, рассматривает как конфиденциальную. Так, например, понимание определенного языка часто строго коррелируется с принадлежностью к определенной этнической группе. Агентам пользователя, которые предлагают возможность конфигурирования содержимого заголовка AcceptLanguage, настоятельно рекомендуется посылать сообщение пользователю о том, что в результате может быть потеряна конфиденциальность определенных данных. Подходом, который ограничивает потерю конфиденциальности для агента пользователя, может быть отказ от посылки заголовков AcceptLanguage по умолчанию. Предполагается при этом каждый раз консультироваться с пользователем относительно возможности посылки этих данных серверу. Пользователь будет принимать решение о посылке AcceptLanguage, лишь убедившись на основании содержимого заголовка отклика Vary в том, что такая посылка существенно улучшит качество обслуживания.

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

Фальсификация DNS

Клиенты, интенсивно использующие HTTP обмен со службой имен домена (Domain Name Service), обычно предрасположены к атакам, базирующимся на преднамеренном некорректном соответствии IP-адресов и DNS-имен. Клиенты должны быть осторожны относительно предположений, связанных с ассоциаций IP-адресов и DNS-имен.

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

Если клиенты HTTP кэшируют результат DNS-запроса для улучшения рабочих характеристик, они должны отслеживать пригодность этих данных с учетом времени жизни, объявляемого DNS-сервером.

Если клиенты HTTP не следуют этому правилу, они могут быть мистифицированы, когда изменится IP-адрес доступного ранее сервера. Так как смена адресов в сетях будет в ближайшее время активно развиваться (IPv6 !), такого рода атаки становятся все более вероятными.

Данное требование улучшает работу клиентов, в том числе с серверами, имеющими идентичные имена.

Заголовки Location и мистификация

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