Parell de sòcol o capçalera reenviada: quina adreça és fiable?

Una sol·licitud que arriba a la vostra aplicació porta dos tipus de proves sobre l’adreça: el parell que va obrir la connexió de xarxa i un camp HTTP que afirma l’adreça d’un client anterior. Responen preguntes diferents. El parell de sòcol s’observa, mentre que la capçalera l’afirma qui l’ha escrit, i cap dels dos no hauria de substituir l’altre en silenci en un registre o en una regla d’accés. La comparació següent els manté separats i després mostra l’única disposició en què la capçalera esdevé utilitzable.

Descriviu el camí abans de comparar res:

Client -> approved reverse proxy -> application origin

En aquesta disposició, el parell de sòcol de l’origen normalment és el servidor intermedi, i una capçalera de reenviament pot portar l’afirmació del servidor intermedi sobre el client. El seu valor prové de la relació controlada amb aquest servidor intermedi, no del nom de la capçalera.

Dos tipus de proves sobre l’adreça

El parell de sòcol és un fet sobre una connexió TCP: alguna cosa va completar un intercanvi de claus des d’aquella adreça. No és necessàriament la persona, el dispositiu o el compte que us importa, perquè una VPN o una sortida de Tor poden ser legítimament la font que observa un servei. Tot i així, és l’única adreça que el mateix amfitrió ha verificat, i aquest és tot el seu valor.

Un camp de reenviament és metainformació sobre una cadena. X-Forwarded-For, X-Real-IP i el camp estandarditzat Forwarded el pot escriure qualsevol client que arribi a un punt final que els reprodueixi, així que la seva fiabilitat depèn totalment de qui va tenir permís per establir-los.

Manteniu tots dos en el context de la sol·licitud amb noms diferents. Una aplicació que sobreescriu el parell amb la capçalera perd la capacitat de reconstruir més tard un error de confiança, que és exactament quan el necessiteu.

Una capçalera no redirigeix mai la connexió

Escriure una adreça en un camp de reenviament no canvia la font de la connexió TCP que arriba al servidor, ni altera l’encaminament enlloc del camí. L’encaminament VPN ordinari o NAT d’origen lliura el trànsit sense cap capçalera HTTP. De la mateixa manera, una passarel·la de trànsit no reescriu un intercanvi HTTPS ben protegit sense canviar la disposició del punt final TLS.

L’error invers és igual de comú: HTTPS no fa veritable una capçalera de reenviament proporcionada pel client. Protegeix el transport d’una afirmació falsa exactament igual com el d’una de verdadera.

Si un col·lega proposa un canvi de capçalera per arreglar un problema d’encaminament, el diagnòstic ja ha anat malament. Arregleu el camí o arregleu la configuració del servidor intermedi que escriu la capçalera.

Anomeneu el servidor intermedi autoritzat a afirmar

Dues regles fan utilitzable un camp de reenviament, i totes dues són configuració i no codi. La vora normalitza o descarta tot el que arriba de fora, segons el seu propi comportament documentat per a aquests camps. L’origen pren després una adreça de substitució del camí de servidor intermedi que heu anomenat i de cap altre lloc. Aquesta segona regla només es manté mentre els clients no poden arribar a l’origen d’una altra manera, ja que un origen que respon tant a sol·licituds directes com a sol·licituds a través de servidor intermedi no sap quina de les dues està servint.

El mòdul d’IP real de NGINX mostra la divisió amb claredat. set_real_ip_from anomena els remitents l’afirmació dels quals compta, i real_ip_header diu quin camp la porta; el primer fa la confiança, el segon només diu on cal mirar.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Una directiva de selecció de capçalera per si sola encara no estableix res sobre qui va enviar el valor.

La seguretat del transport ha de recórrer tot el camí entre els components en què confieu. Una vora que normalitza correctament perd aquest valor en el moment que un salt no protegit més avall permet que algú altre editi l’afirmació mentre viatja.

Gestioneu deliberadament les cadenes de diversos salts

Diversos servidors intermediaris necessiten un model de cadena explícit. No prengueu el valor més a l’esquerra o més a la dreta separat per comes perquè algun article de blog ho va fer; esbrineu quin dels vostres servidors intermediaris afegeix, quin substitueix i quin conserva el camp entrant. NGINX, per exemple, pot recórrer la llista cap enrere contra el seu conjunt de confiança i aturar-se a la primera adreça que no posseeix, i aquesta és la regla d’aquest producte, no una llei que segueixi cada marc de treball. Llegiu la documentació del vostre servidor intermedi amb les mateixes dues preguntes: quin valor selecciona i en quins remitents creu?

Escriviu la cadena: ordre de salts, quin salt estableix el camp i quin salt elimina les còpies entrants. Després manteniu aquesta nota al costat de la configuració del servidor intermedi, no només al tiquet. Després proveu-ho enviant una sol·licitud amb una capçalera falsificada pel procés de validació aprovat i confirmant que l’origen la ignora.

Quan afegiu un salt, reviseu aquest document. Un nou balancejador de càrrega inserit davant del servidor intermedi de confiança pot canviar quina adreça guanya sense que ningú editi l’aplicació.

Manteniu les dues observacions al registre

On el diagnòstic està autoritzat, registreu el parell de la connexió i l’adreça de client normalitzada com a dos camps separats, i afegiu només les metainformacions de reenviament que la finalitat necessiti realment. Després demostreu el desplegament amb dues sol·licituds: una a través del servidor intermedi que hauria de registrar els dos valors de manera sensata, i un intent directe a l’origen que ha de ser refusat.

Recordeu què significa la parella. La capçalera afegeix context proporcionat per un component que heu triat confiar; el parell continua sent l’única adreça que el vostre amfitrió ha vist realment. Cap de les dues no és prova d’identitat individual, i un disseny que tracti qualsevol de les dues com a prova s’equivocarà respecte d’algú.