Есть ли стандарт для цепочки заголовков x-forwarded-for?
IETF RFC 2616, раздел 4.2, позволяет запросу содержать несколько заголовков с одинаковым именем поля, если сохраняется хронологический порядок вставки и их значения могут быть преобразованы в один заголовок с разделенным запятыми списком значений.
http://tools.ietf.org/html/rfc2616
поля заголовка сообщения с одним и тем же именем поля МОГУТ присутствовать в сообщении тогда и только тогда, когда все значение поля для этого поля заголовка определено как список, разделенный запятыми [т.е. #(значения)]. ДОЛЖНО быть возможно объединить несколько полей заголовка в одну пару "field-name: field-value", не изменяя семантику сообщения, добавляя каждое последующее значение поля к первому, каждое из которых разделяется запятой. Порядок, в котором принимаются поля заголовка с одним и тем же именем поля, поэтому важен для интерпретации объединенного значения поля, и, таким образом, прокси-сервер НЕ ДОЛЖЕН изменять порядок этих значений поля при пересылке сообщения. F5 не будет перезаписывать любые существующие X-Forwarded-For. Он также не объединит существующие X-Forwarded-For в одно значение, разделенное запятыми. Вместо этого он вставит дополнительный X-Forwarded-For в хвостовую часть коллекции.
Но как насчет среды с несколькими клиентами, прокси, CDN, диспетчерами трафика, серверами, которые занимаются манипулированием X-Forwarded-For коллекция?
Казалось бы, есть преимущество в применении единой практики. Но какова лучшая практика?
F5 BIG-IP по умолчанию заголовок вставки профиля http накапливает дополнительный X-Forwarded-For в конце уже существующей коллекции заголовков XFF запроса, сохраняя порядок.
AWS ELB поощряет объединение нескольких входящих запросов X-Forwarded-For в один заголовок, содержащий разделенный запятыми список IP-адресов XFF плюс адрес хоста пользователя, сохраняя порядок.
Другие устройства могут использовать другие варианты.
Существует ли согласованная рекомендация или фактический стандарт для разнородных сред?
Кроме того, предоставлены ли какие-либо временные данные, которые позволят коду окончательно сортировать X-Forwarded-For Заголовки в хронологическом порядке сложения для случая, когда подозрительны предыдущие манипуляции с заголовками XFF.
1 ответ
Да, есть стандарт: вообще не используйте X-Forwarded-For.
RFC 7239 определяет заголовок Forwarded, который имеет довольно отличную семантику от X-Forwarded-For, и новые реализации должны использовать его. К сожалению, он страдает от той же проблемы, которую вы определили с помощью X-Forwarded-For здесь: он может быть задан дважды в запросе или содержать список значений через запятую. Прокси также могут удалить его полностью.
И да, есть лучшая практика: использовать другое имя заголовка внутри.
Помните, что X-Forwarded-For и его замена Forwarded содержат ненадежный ввод. Для клиента тривиально поместить в заголовок все, что он хочет. Если вам действительно нужно знать публичный IP-адрес того, что подключено к вашему серверу, вставьте его в другой заголовок. Например, CloudFlare использует CF-Connecting-IP для этой цели. Я также видел Client-IP и X-Real-IP, используемые в nginx (где вы можете определить все, что захотите). Какое бы имя ни использовалось, ваши балансировщики нагрузки должны отправлять IP-адрес запрашивающего в каком-либо заголовке, отличном от X-Forwarded-For или Forwarded.