RFC 7239 | HTTP-расширение «Forwarded» (Переадресовано) — efim360.ru

RFC 7239 | HTTP-расширение "Forwarded" (Переадресовано)

Введение

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

В этом документе также указаны рекомендации для администратора прокси-сервера по анонимизации источника запроса.

Скачать оригинальную версию документа на английском языке можно в RFC 7239 PDF

 

Оглавление

1. Введение
2. Условные обозначения
3. Синтаксические обозначения
4. Поле заголовка HTTP "Forwarded" (Перенаправлено)
5. Параметры
5.1. "Forwarded By"
5.2. "Forwarded For"
5.3. "Forwarded Host"
5.4. "Forwarded Proto"
5.5. Расширения
6. Идентификаторы узлов
6.1. Идентификаторы IPv4 и IPv6
6.2. Идентификатор "unknown"
6.3. Запутанный идентификатор
7. Вопросы реализации
7.1. HTTP-списки
7.2. Сохранение полей заголовка
7.3. Отношение к "Via"
7.4. Переход
7.5. Пример использования
8. Вопросы безопасности
8.1. Валидность и Целостность заголовка
8.2. Утечка информации
8.3. Соображения конфиденциальности
9. Соображения IANA
10. Ссылки
10.1. Нормативные ссылки
10.2. Информативные ссылки
Приложение А. Благодарности

 

1. Введение

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

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

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

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

Обычный способ раскрыть эту информацию - использовать нестандартные поля заголовка, такие как:

  • X-Forwarded-For
  • X-Forwarded-By
  • X-Forwarded-Proto

Существует много преимуществ использования стандартизированного подхода к обычно желаемым функциям протокола: не в последнюю очередь это возможность взаимодействия между реализациями. Этот документ стандартизирует поле заголовка под названием "Forwarded" (Перенаправлено) и предоставляет синтаксис и семантику для раскрытия такой информации. Заголовок "Forwarded" (Перенаправлено) также объединяет всю информацию в одном поле заголовка, что позволяет сопоставлять эту информацию. С форматом поля заголовка, описанным в этом документе, можно узнать, какая информация принадлежит друг другу, если прокси-серверы являются доверенными. Такие выводы невозможно сделать с полями заголовка класса "X-Forwarded". Поле заголовка, определённое в этом документе, является необязательным, так что реализации прокси-серверов, предназначенные для обеспечения конфиденциальности, не требуются для работы или реализации поля заголовка.

Обратите внимание, что проблемы, подобные описанным для прокси-серверов, также возникают при использовании NAT. Это обсуждается далее в [RFC6269 #].

 

2. Условные обозначения

Ключевые слова «ОБЯЗАН - MUST», «НЕ ОБЯЗАН - MUST NOT», «ТРЕБУЕТСЯ - REQUIRED», «ДОЛЖЕН - SHALL», «НЕ ДОЛЖЕН - SHALL NOT», «СЛЕДУЕТ - SHOULD», «НЕ СЛЕДУЕТ - SHOULD NOT», «РЕКОМЕНДУЕТСЯ - RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ - NOT RECOMMENDED», «ВОЗМОЖЕН - MAY» и «ДОПОЛНИТЕЛЬНО - OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

 

3. Синтаксические обозначения

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) [RFC5234 #] с расширением правила списка, определенным в разделе 7 [RFC7230 #].

 

4. Поле заголовка HTTP "Forwarded" (Перенаправлено)

Поле заголовка HTTP "Forwarded" является НЕОБЯЗАТЕЛЬНЫМ полем заголовка, которое при использовании содержит список пар "параметр-идентификатор", которые раскрывают информацию, которая изменяется или теряется, когда прокси участвует в пути запроса. Из-за конфиденциального характера данных, передаваемых в этом поле заголовка (см. разделы 8.2 и 8.3), это поле заголовка должно быть отключено по умолчанию. Далее каждый параметр следует настраивать индивидуально. "Forwarded" предназначен только для использования в HTTP-запросах и не должен использоваться в HTTP-ответах. Это касается как форвардинговых прокси, так и обратных прокси. Информация, передаваемая в этом поле заголовка, может быть, например, исходным IP-адресом запроса, IP-адресом входящего интерфейса на прокси-сервере или используемым протоколом HTTP или HTTPS. Если запрос проходит через несколько прокси, каждый прокси может добавить набор параметров; он также может удалить ранее добавленные поля заголовка "Forwarded".

 

Список верхнего уровня представлен в виде списка значений полей заголовка HTTP, как определено в разделе 3.2 [RFC7230 #]. Первый элемент в этом списке содержит информацию, добавленную первым прокси-сервером, который реализует и использует это поле заголовка, а каждый последующий элемент содержит информацию, добавленную каждым последующим прокси-сервером. Поскольку это поле заголовка является необязательным, любой прокси в цепочке может не обновлять это поле заголовка. Каждое значение поля представляет собой список, разделённый точкой с запятой; этот подсписок состоит из пар "параметр-идентификатор". Пары "параметр-идентификатор" группируются знаком равенства. Каждый параметр НЕ ДОЛЖЕН встречаться более одного раза для значения поля. Имена параметров нечувствительны к регистру. Значение поля заголовка может быть определено в синтаксисе ABNF как:

 

Forwarded = 1#forwarded-element

forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] )

forwarded-pair = token "=" value
value = token / quoted-string

token = <Определено в [RFC7230 #], Section 3.2.6>
quoted-string = <Определено в [RFC7230 #], Section 3.2.6>

 

Примеры:

Forwarded: for="_gazonk"
Forwarded: For="[2001:db8:cafe::17]:4711"
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for=198.51.100.17

 

Обратите внимание, что, поскольку «:» и «[]» не являются допустимыми символами в «токенах», адреса IPv6 записываются как «строка в кавычках».

Прокси-сервер, который хочет добавить новое значение поля заголовка "Forwarded", может либо добавить его к последнему существующему полю заголовка "Forwarded" после разделителя-запятой, либо добавить новое поле в конце блока заголовка. Прокси-сервер МОЖЕТ удалить из запроса все поля заголовка "Forwarded". Однако он ДОЛЖЕН гарантировать, что правильное поле заголовка обновляется в случае нескольких полей заголовка "Forwarded".

 

5. Параметры

В этом документе указывается ряд параметров и допустимые значения для каждого из них:

o "by" идентифицирует интерфейс прокси-сервера, обращённый к пользовательскому агенту.

o "for" идентифицирует узел, делающий запрос к прокси.

o "host" - это поле заголовка запроса хоста, полученное прокси-сервером.

o "proto" указывает, какой протокол использовался для выполнения запроса.

 

5.1. "Forwarded By"

Параметр "by" используется для раскрытия интерфейса, через который поступил запрос на прокси-сервер. Когда прокси выбирают использование параметра "by", его конфигурация по умолчанию ДОЛЖНА содержать "запутанный" идентификатор, как описано в Разделе 6.3. Если серверу, получающему проксированные запросы, требуются некоторые функции на основе адреса, этот параметр МОЖЕТ вместо этого содержать IP-адрес (и, возможно, номер порта). Третий вариант - идентификатор "unknown" («Неизвестный»), описанный в Разделе 6.2.

Синтаксис значения "by" после возможного восстановления строки в кавычках соответствует ABNF «узла» ("node"), описанному в Разделе 6.

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

 

5.2. "Forwarded For"

Параметр "for" используется для раскрытия информации о клиенте, инициировавшем запрос, и последующих прокси в цепочке прокси. Когда прокси выбирают использование параметра "for", его конфигурация по умолчанию ДОЛЖНА содержать "запутанный" идентификатор, как описано в Разделе 6.3. Если серверу, получающему проксированные запросы, требуются некоторые функции на основе адреса, этот параметр МОЖЕТ вместо этого содержать IP-адрес (и, возможно, номер порта). Третий вариант - идентификатор "unknown" («Неизвестный»), описанный в Разделе 6.2.

 

Синтаксис значения "for" после возможного восстановления строки в кавычках соответствует ABNF «узла» ("node"), описанному в Разделе 6.

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

 

5.3. "Forwarded Host"

Параметр "host" используется для пересылки исходного значения поля заголовка "Host". Это может быть использовано, например, исходным сервером, если обратный прокси-сервер перезаписывает поле заголовка "Host" на какое-то внутреннее имя хоста.

Синтаксис значения "host" после возможного восстановления строки в кавычках ДОЛЖЕН соответствовать ABNF узла, описанному в Разделе 5.4 [RFC7230 #].

 

5.4. "Forwarded Proto"

Параметр "proto" имеет значение используемого типа протокола. Синтаксис значения "proto" после возможного восстановления строки в кавычках ДОЛЖЕН соответствовать имени схемы URI, как определено в разделе 3.1 в [RFC3986] и зарегистрирован в IANA в соответствии с [RFC4395]. Типичными значениями являются "http" или "https".

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

 

5.5. Расширения

Расширения позволяют использовать дополнительные параметры и значения. Расширения могут быть особенно полезны в средах обратного прокси. Все параметры расширения СЛЕДУЕТ зарегистрировать в реестре "HTTP Forwarded Parameter". Если ожидается широкое распространение определённых расширений, их СЛЕДУЕТ также стандартизировать. Это обсуждается далее в Разделе 9.

 

6. Идентификаторы узлов

Идентификатор узла может быть одним из следующих:

  • IP-адрес клиента с необязательным номером порта
  • Маркер, указывающий, что IP-адрес клиента не известен прокси-серверу.
  • Сгенерированный токен, позволяющий отслеживать и отлаживать, позволяя скрыть внутреннюю структуру или конфиденциальную информацию.

 

Идентификатор узла определяется синтаксисом ABNF как:

 

node = nodename [ ":" node-port ]
nodename = IPv4address / "[" IPv6address "]" /
"unknown" / obfnode

IPv4address = <Определён в [RFC3986], Section 3.2.2>
IPv6address = <Определён в [RFC3986], Section 3.2.2>
obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-")

node-port = port / obfport
port = 1*5DIGIT
obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-")

DIGIT = <Определён в [RFC5234], Section 3.4>
ALPHA = <Определён в [RFC5234], Section B.1>

 

Каждый из идентификаторов может дополнительно иметь идентификатор порта, например, позволяющий идентифицировать конечную точку в среде с NAT. "Узел-порт" ("node-port") может быть идентифицирован либо по его номеру порта, либо по сгенерированному токену, скрывающему реальный номер порта. Замаскированный порт может использоваться в ситуациях, когда владелец прокси-сервера хочет иметь возможность отслеживать запросы -- например, в целях отладки -- но не хочет раскрывать внутреннюю информацию.

Обратите внимание, что приведённый выше ABNF также позволяет добавлять номера портов к идентификатору "unknown" («Неизвестный»). Однако интерпретация такой записи остаётся за владельцем прокси, добавляющего такое значение в поле заголовка. Чтобы отличить "obfport" от порта, "obfport" ДОЛЖЕН иметь начальное подчёркивание. Кроме того, он ДОЛЖЕН также состоять только из "ALPHA", "DIGIT" и символов «.», «_» и «-».

Важно отметить, что адрес IPv6 и любое имя узла с указанным портом узла ДОЛЖНЫ быть заключены в кавычки, поскольку «:» не является допустимым символом в "токенах" ("token").

 

Примеры:

"192.0.2.43:47011"
"[2001:db8:cafe::17]:47011"

 

6.1. Идентификаторы IPv4 и IPv6

Правила ABNF для "IPv6-адрес" и "IPv4-адрес" определены в [RFC3986]. "IPv6-адрес" ДОЛЖЕН соответствовать рекомендациям по текстовому представлению [RFC5952] (например, строчные буквы, сжатие нулей).

Обратите внимание, что IP-адрес может быть адресом внутренней сети, как определено в [RFC1918] и [RFC4193]. Также обратите внимание, что адрес IPv6 всегда заключен в квадратные скобки.

 

6.2. Идентификатор "unknown"

Идентификатор "unknown" («Неизвестный») используется, когда личность предшествующего объекта неизвестна, но прокси-сервер все еще хочет сигнализировать о пересылке запроса. Одним из примеров может быть процесс прокси-сервера, генерирующий исходящий запрос без прямого доступа к TCP-сокету входящего запроса.

 

6.3. Запутанный идентификатор

Сгенерированный идентификатор можно использовать, если необходимо сохранить в секрете внутренние IP-адреса, но при этом разрешить использование поля заголовка "Forwarded" для отслеживания и отладки. Это также может быть полезно, если прокси использует какие-то метки интерфейса и есть желание передать их, а не IP-адрес. Если для использования сервером идентификаторов не требуется статическое присвоение идентификаторов, запутанные идентификаторы ДОЛЖНЫ генерироваться случайным образом для каждого запроса. Если сервер требует, чтобы идентификаторы сохранялись между запросами, они НЕ ДОЛЖНЫ сохраняться дольше, чем IP-адреса клиентов. Чтобы отличить запутанный идентификатор от других идентификаторов, он ДОЛЖЕН иметь начальное подчеркивание «_». Кроме того, он ДОЛЖЕН также состоять только из "ALPHA", "DIGIT" и символов «.», «_» и «-».

Пример:

Forwarded: for=_hidden, for=_SEVKISEK

 

7. Вопросы реализации

7.1. HTTP-списки

Обратите внимание, что список HTTP допускает наличие пробелов между идентификаторами, и список может быть разбит на несколько полей заголовка. Например, поле заголовка

Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown

эквивалентно полю заголовка

Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown

что эквивалентно полям заголовка

Forwarded: for=192.0.2.43
Forwarded: for="[2001:db8:cafe::17]", for=unknown

 

7.2. Сохранение полей заголовка

Есть некоторые случаи, когда это поле заголовка следует сохранить, а в некоторых случаях его не следует сохранять. Непосредственно перенаправленный запрос должен сохранять и, возможно, расширять его. Если один входящий запрос заставляет прокси-сервер выполнять несколько исходящих запросов, необходимо принять особое внимание, чтобы решить, следует ли сохранять поле заголовка. Во многих случаях поле заголовка должно быть сохранено, но если исходящий запрос не является прямым следствием входящего запроса, поле заголовка не должно сохраняться. Рассмотрим также случай, когда прокси-сервер обнаружил несоответствие содержимого в ответе 304 и следует инструкциям в [RFC7232], раздел 4.1, чтобы безоговорочно повторить запрос, и в этом случае новый запрос по-прежнему является прямым следствием исходного запроса, и поле заголовка, вероятно, следует сохранить.

 

7.3. Отношение к "Via"

Поле заголовка "Via" (см. [RFC7230], раздел 5.7.1) - это поле заголовка с тем же вариантом использования, что и это поле заголовка. Однако поле заголовка "Via" предоставляет информацию только о самом прокси-сервере и, таким образом, не включает информацию о клиенте, подключающемся к прокси-серверу. Поле заголовка "Forwarded", с другой стороны, в качестве основного назначения имеет ретрансляцию информации с клиентской стороны прокси-сервера. Поскольку "Via" уже широко используется, его формат нельзя изменить для решения проблем, которые решает "Forwarded".

Обратите внимание, что невозможно объединить информацию из этого поля заголовка с информацией из поля заголовка "Via". Некоторые прокси-серверы не будут обновлять поле заголовка "Forwarded", некоторые прокси-серверы не будут обновлять поле заголовка "Via", а некоторые прокси-серверы будут обновлять и то, и другое.

 

7.4. Переход

Если прокси-сервер получает входящие запросы с полями заголовка X-Forwarded-*, рекомендуется преобразовать их в поле заголовка, описанное в этом документе, если это можно сделать разумным способом. Если запрос содержит только один тип, например "X-Forwarded-For", его можно преобразовать в "Forwarded", добавив перед каждым элементом "for=". Обратите внимание, что IPv6-адреса не могут быть заключены в кавычки в "X-Forwarded-For" и не могут быть заключены в квадратные скобки, но они заключены в кавычки и заключены в квадратные скобки в "Forwarded".

X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17

становится:

Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"

Однако следует соблюдать особую осторожность, если, например, существуют и "X-Forwarded-For", и "X-Forwarded-By". В таких случаях может оказаться невозможным выполнить преобразование, поскольку невозможно узнать, в каком порядке были добавлены уже существующие поля. Также обратите внимание, что удаление поля заголовка "X-Forwarded-For" может вызвать проблемы у сторон, которые еще не реализовали поддержку этого нового поля заголовка.

 

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

Запрос от клиента с IP-адресом 192.0.2.43 проходит через прокси-сервер с IP-адресом 198.51.100.17, затем через другой прокси-сервер с IP-адресом 203.0.113.60, прежде чем достичь исходного сервера. Например, это может быть офисный клиент за корпоративным фильтром вредоносных программ, который общается с исходным сервером через обратный прокси-сервер.

  • HTTP-запрос между клиентом и первым прокси-сервером не имеет поля заголовка "Forwarded".
  • HTTP-запрос между первым и вторым прокси-сервером имеет поле заголовка "Forwarded: for=192.0.2.43".
  • HTTP-запрос между вторым прокси-сервером и исходным сервером имеет поле заголовка "Forwarded: for=192.0.2.43,for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com".

Обратите внимание, что в некоторых точках цепочки подключения информация в поле заголовка "Forwarded" может не обновляться либо из-за отсутствия поддержки этого расширения HTTP, либо из-за решения политики не раскрывать информацию об этом сетевом компоненте.

 

8. Вопросы безопасности

8.1. Валидность и Целостность заголовка

Нельзя полагаться на правильность поля заголовка HTTP "Forwarded", поскольку оно может быть изменено по ошибке или по злонамеренным причинам каждым узлом на пути к серверу, включая клиента, делающего запрос.

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

 

8.2. Утечка информации

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

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

 

8.3. Соображения конфиденциальности

В последние годы растёт озабоченность по поводу конфиденциальности. Существует компромисс между обеспечением конфиденциальности для пользователей и раскрытием информации, которая полезна, например, для отладки, статистики и создания контента, зависящего от местоположения. Поле заголовка HTTP "Forwarded" по своей конструкции предоставляет информацию, которую некоторые пользователи считают конфиденциальной, чтобы разрешить такое использование. Для любого прокси-сервера, если HTTP-запрос содержит поля заголовка, которые специально запрашивают семантику конфиденциальности, прокси-сервер НЕ ДОЛЖЕН использовать поле заголовка "Forwarded" или каким-либо другим образом передавать личную информацию, например IP-адреса, на следующий переход.

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

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

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

Конфигурация по умолчанию для параметров "by" и "for" ДОЛЖНА содержать запутанные идентификаторы. Эти идентификаторы ДОЛЖНЫ генерироваться случайным образом для каждого запроса. Если требуются идентификаторы, сохраняющиеся между запросами, их время жизни ДОЛЖНО быть ограничено, и они НЕ ДОЛЖНЫ сохраняться дольше, чем IP-адреса клиентов. При создании запутанных идентификаторов необходимо соблюдать осторожность, чтобы не включать в них потенциально конфиденциальную информацию.

Обратите внимание, что IP-адреса пользователей уже могут пересылаться прокси-серверами с использованием поля заголовка "X-Forwarded-For", которое широко используется. Следует также отметить, что если бы пользователь выполнял подключение напрямую, минуя прокси, IP-адрес клиента был бы отправлен на веб-сервер. Пользователи, которые не выбирают активно анонимный прокси-сервер, не могут рассчитывать на защиту своего IP-адреса. Эти пользователи, которые хотят свести к минимуму риск быть отслеженным, также должны помнить, что существуют и другие способы утечки информации, например, путём снятия отпечатков пальцев в поле заголовка браузера. Само поле заголовка "Forwarded", даже если оно используется без уникального идентификатора клиента, может сделать снятие отпечатков пальцев более осуществимым, раскрывая цепочку прокси-серверов, через которые проходит клиентский запрос.

 

 

9. Соображения IANA

В этом документе указано поле заголовка HTTP, указанное ниже, которое было добавлено в реестр «Постоянные имена полей заголовка сообщения», определённый в [RFC3864].

Header field: Forwarded
Applicable protocol: http
Status: standard
Author/Change controller:
IETF (iesg@ietf.org)
Internet Engineering Task Force
Specification document(s): this specification (Section 4)
Related information: None

 

Поле заголовка "Forwarded" содержит параметры, для которых IANA создала и теперь поддерживает новый реестр под названием "HTTP Forwarded Parameters". Первоначальные регистрации приведены ниже. Для будущих заданий используется процедура регистрации IETF Review [RFC5226]. Последствия всех новых параметров для безопасности и конфиденциальности должны быть тщательно задокументированы. Новые параметры и их значения ДОЛЖНЫ соответствовать пересылаемой паре, как определено в ABNF в Разделе 4. Кроме того, при регистрации должно быть предоставлено краткое описание.

Имя параметра Описание Ссылка
by IP адрес входящего интерфейса прокси Раздел 5.1
for IP-адрес клиента, делающего запрос через прокси Раздел 5.2
host Поле заголовка хоста входящего запроса Раздел 5.3
proto Протокол приложения, используемый для входящего запроса Раздел 5.4

 

 

10. Ссылки

10.1. Нормативные ссылки

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.

[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
June 2014.

 

10.2. Информативные ссылки

[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.

 

Приложение А. Благодарности

Спасибо Перу Седерквисту (Per Cederqvist), Алиссе Купер (Alissa Cooper), Адриану Фаррелу (Adrian Farrel), Стивену Фарреллу (Stephen Farrell), Неду Фриду (Ned Freed), Перу Хедбору (Per Hedbor), Амосу Джеффрису (Amos Jeffries), Полу-Хеннинг Кампу (Poul-Henning Kamp), Мюррею С. Кучерави (Murray S. Kucherawy), Барри Лейбе (Barry Leiba), Сальваторе Лорето (Salvatore Loreto), Алексею Мельникову (Alexey Melnikov), С. Мунесами (S. Moonesamy), Сьюзен Николс (Susan Nichols), Марку Ноттингему (Mark Nottingham), Джулианне Решке (Julian Reschke), Джону Сулливану (John Sullivan), Вилли Террау (Willy Tarreau) и Дэну Вингу (Dan Wing) за их отзывы.

 

Адрес автора

Andreas Petersson
Opera Software

EMail: andreas@sbin.se

Martin Nilsson
Opera Software
S:t Larsgatan 12
Linkoping SE-582 24

EMail: nilsson@opera.com

 

Статус этого меморандума

Это документ для отслеживания стандартов Интернета.

Этот документ является продуктом Инженерной группы Интернета (IETF). Он представляет собой консенсус сообщества IETF. Он прошел общественное обсуждение и был одобрен для публикации Руководящей группой Internet Engineering (IESG). Дополнительная информация об интернет-стандартах доступна в разделе 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и о том, как оставить отзыв о нем, можно получить по адресу http://www.rfc-editor.org/info/rfc7239.

 

Уведомление об авторских правах

Copyright (c) 2014 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

Этот документ регулируется BCP 78 и Юридическими положениями IETF Trust, касающимися документов IETF (http://trustee.ietf.org/license-info), действующими на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Юридических положений о доверии, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.