Resumen

  • Forwarded y X-Forwarded-For contienen afirmaciones sobre el trayecto, no una identidad autenticada. La observación local es el par de transporte; solo se retrocede por una parte de la cadena autorizada.
  • La prueba operativa debe conservar líneas y orden originales, gramática, política de confianza, primer límite no fiable y decisión consumidora. Una dirección bien escrita no posee autoridad por sí sola.

El valor correcto de la fuente equivocada

El diagnóstico habitual, «las cabeceras se pueden falsificar», no localiza el control perdido. El cliente siempre puede aportar texto HTTP. El fallo aparece cuando el receptor confunde ese texto con una observación propia.

El socket ofrece un dato más estrecho: quién estableció el enlace inmediato. Puede ser un balanceador y no la persona originaria, pero es el punto desde el que puede comenzar una delegación. Si ese par no figura entre quienes pueden presentar metadatos de reenvío, la búsqueda termina allí. Leer el elemento izquierdo pese a ello concede al solicitante el poder de elegir su propia procedencia.

Lo que realmente expresa RFC 7239

RFC 7239 define Forwarded como un campo opcional para revelar información alterada o perdida al atravesar un proxy. Sus parámetros for, by, host y proto describen relaciones distintas. Que aparezcan juntos permite correlacionarlos; no los convierte en una credencial.

El propio estándar rechaza una presunción de integridad. Cualquier nodo del camino, incluido el cliente, puede modificar el campo por error o con intención. Autorizar proxies comprobados permite confiar de manera acotada en lo que esos proxies observaron. No autentica el prefijo arbitrario que ya habían recibido. Tampoco protege un enlace posterior inseguro.

Los identificadores unknown u ofuscados son estados previstos, no direcciones que deban forzarse a una forma numérica. Un registro riguroso separa ausencia, reserva de privacidad, error y dirección interpretada.

XFF tiene otro contrato

X-Forwarded-For es una convención anterior y no comparte automáticamente la gramática de RFC 7239. AWS ALB, por ejemplo, permite anexar, preservar o eliminar XFF. Al anexar, mantiene el contenido recibido y añade a la derecha la dirección observada. Esa adición no autentica lo que quedaba a la izquierda.

HAProxy documenta por separado la inserción de XFF y la producción del campo normalizado. Por eso el consumidor debe conocer nombre, posición, limpieza y algoritmo exactos. Elegir siempre «primero» o «último» sin el contrato del emisor no es una política de confianza.

La cadena se ancla en el extremo cercano

En NGINX, set_real_ip_from designa a los emisores conocidos por enviar valores correctos. Con real_ip_recursive on, la búsqueda termina en la última dirección no fiable; $realip_remote_addr conserva el par original.

Apache mod_remoteip recorre de derecha a izquierda y advierte que un usuario puede suplantar trivialmente otra dirección si no se limita a intermediarios confiables. Envoy cuenta saltos desde la derecha con reglas que dependen de use_remote_address, o puede usar CIDR confiables.

La variedad no crea una receta universal de «IP real». Obliga a demostrar la topología de cada listener. Añadir un CDN, omitir un proxy o abrir una ruta alternativa cambia qué posición representa el primer testigo no fiable.

Las líneas duplicadas son una prueba de consenso

RFC 9110 permite combinar, en orden de recepción y con comas, líneas repetidas de campos definidos como listas. El proxy puede ver varias líneas, la biblioteca una cadena única y la aplicación un arreglo. Si autorización y registro no conservan el mismo orden, el supuesto rastro de auditoría no explica la decisión.

IPv6 añade límites que rompen los separadores ingenuos: dos puntos internos, puerto, corchetes y comillas. Los ensayos deben incluir IPv6 con puerto, IPv4 con puerto, unknown, nodos ofuscados, espacios, duplicados y delimitadores defectuosos. Normalizar una cadena y autorizar a su emisor siguen siendo resultados distintos.

host y proto tampoco prueban origen

Tras terminar TLS, un servicio puede usar host y esquema reenviados para redirecciones, cookies seguras o URL absolutas. Un proto=https escrito por el cliente no demuestra que el borde confiable haya observado TLS. Un host transmitido no autentica el origen solicitado.

Cada parámetro necesita una fuente y un consumidor declarados. Se puede aceptar la dirección observada por un balanceador y, a la vez, obtener el host público de un mapa fijo. La confianza útil para un parámetro no debe extenderse en silencio a todo el campo.

PROXY protocol pertenece a otra capa

PROXY protocol presenta dirección de origen y destino antes de HTTP. No adquiere autenticidad por aparecer antes. El receptor ha de esperarlo en un listener dedicado o filtrado y aceptar emisores concretos. En caso contrario, cualquier cliente puede redactar un preámbulo con una fuente inventada.

El par efectivo, la aceptación del preámbulo, el valor declarado y las cabeceras posteriores deben formar registros separados. Sobrescribirlos todos en client_ip elimina la custodia de la evidencia.

Especificar con intentos que deben fallar

Primero se intenta alcanzar el origen fuera del borde. Si la arquitectura lo prohíbe, el enlace debe caer antes de HTTP. Luego se envía una dirección permitida desde un par no autorizado y se comprueba que no se adopta.

Por la ruta legítima, se antepone una dirección falsa, se intercala un proxy no fiable y se añade o quita un salto. Se envían líneas repetidas y variantes difíciles de IPv6. Borde, origen, framework, limitador, autorización y logs deben resolver el mismo valor por la misma razón. Finalmente, un preámbulo PROXY desde una fuente no autorizada debe rechazarse.

El archivo de configuración describe una intención. Estas discordancias hostiles revelan la regla que de verdad está ejecutándose.