Кратко

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

Парсер не был виноват

Фраза «заголовки можно подделать» верна, но не определяет место отказа. HTTP-заголовок всегда является входом от отправителя. Опасный переход происходит, когда приложение превращает этот вход в собственное наблюдение о соединении.

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

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

Что ограничивает RFC 7239

RFC 7239 определяет необязательное поле Forwarded, раскрывающее сведения, изменённые или потерянные при работе прокси. Параметры for, by, host и proto описывают разные части одного перехода. Их корреляция полезна, но не равна удостоверению личности.

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

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

XFF живёт по другому договору

X-Forwarded-For широко распространён, но не является полем RFC 7239. Например, AWS ALB умеет дополнять, сохранять или удалять XFF. В режиме append он оставляет входное содержимое и добавляет справа адрес, который наблюдал. Участие балансировщика объясняет добавленный элемент, но не заверяет значения слева.

HAProxy отдельно документирует вставку XFF и формирование стандартного Forwarded. Получателю необходимо знать точное имя поля, позицию добавления, очистку и алгоритм чтения. Правило «всегда первый» или «всегда последний» без контракта отправителя не имеет основания.

Цепочка начинается у ближнего края

NGINX через set_real_ip_from задаёт источники, которым разрешено присылать корректную замену. При real_ip_recursive on после прохода доверенной части выбирается последний недоверенный адрес; $realip_remote_addr сохраняет исходного соседа.

Apache mod_remoteip рассматривает список справа налево и предупреждает: без ограничения посредников пользователь тривиально выдаёт себя за другой адрес. Envoy также отсчитывает доверенные переходы справа, причём результат зависит от use_remote_address; при известной сетевой топологии возможна проверка по CIDR.

Универсальной команды «получить реальный IP» не существует. Есть конкретный listener, проверенный сосед, заявленная топология и место остановки. Добавление CDN, удаление прокси или новый прямой маршрут меняют эту границу.

Повторные строки проверяют согласие систем

RFC 9110 разрешает объединять повторные строки списочных полей по порядку получения через запятую. Прокси может видеть несколько строк, библиотека — одну строку, framework — массив. Намеренные повторы показывают, одинаково ли читают запрос фильтр, авторизация и журнал.

IPv6 ломает наивное разделение по двоеточию. Порт, скобки и кавычки добавляют границы. Нужны тесты с IPv6 и портом, IPv4 и портом, unknown, обфусцированными узлами, пробелами и неверными разделителями.

Нормализация отвечает, какое значение прочитано. Доверие отвечает, почему отправитель имел право его предоставить. Это разные записи.

host и proto тоже не удостоверяют источник

После завершения TLS приложение может использовать переданные схему и host для перенаправлений, абсолютных URL и Secure cookie. Но клиентское proto=https не доказывает, что доверенный edge наблюдал TLS. Переданный host не аутентифицирует origin.

Для каждого параметра нужны отдельные источник и потребитель. Адрес можно принять от edge, а публичный host — взять из фиксированной карты. Полезность одного параметра не должна незаметно расширять доверие ко всему полю.

PROXY protocol — отдельная книга доказательств

PROXY protocol передаёт источник и назначение до HTTP. Более раннее положение не делает содержимое аутентичным. Получатель должен ожидать префикс на выделенном или строго фильтрованном listener и принимать только уполномоченных отправителей. Иначе любой клиент заявит произвольный источник.

Фактический сосед, ожидание и принятие префикса, заявленный адрес и последующие HTTP-поля должны храниться отдельно. Перезапись всего в одну переменную client_ip уничтожает происхождение доказательств.

Спецификацию пишут отказы

Сначала следует обратиться к origin в обход edge. Если архитектура запрещает путь, соединение должно завершиться до HTTP. Затем недоверенный сосед отправляет разрешённый адрес в XFF, который не должен приниматься.

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

Конфигурация показывает намерение. Эти враждебные расхождения показывают исполняемое правило.