Socket-peer eller videresendt header: kva adresse skal du stole på?

Ein førespurnad som kjem inn til applikasjonen din, ber to slag adresseprov: peeren som opna nettverkssambandet, og eit HTTP-felt som hevdar adressa til ein tidlegare klient. Dei svarar på ulike spørsmål. Socket-peeren blir observert, medan headeren blir hevda av den som skreiv han, og ingen av dei bør stille erstatte den andre i ein logg eller ei tilgangsregel. Samanlikninga nedanfor held dei fråskilde og viser deretter det einaste arrangementet der headeren blir brukbar.

Skildre stien før du samanliknar noko:

Client -> approved reverse proxy -> application origin

I det arrangementet er socket-peeren til opphavet normalt proxyen, og ein videresendt header kan bera påstanden til proxyen om klienten. Verdien kjem frå det kontrollerte tilhøvet til den proxyen, ikkje frå namnet på headeren.

To slag adresseprov

Socket-peeren er eit faktum om éin TCP-samband: noko fullførte eit handtrykk frå den adressa. Det er ikkje nødvendigvis mennesket, eininga eller kontoen du bryr deg om, fordi ein VPN eller ein Tor-utgang lovleg kan vere kjelda ei teneste observerer. Han er likevel den einaste adressa verten sjølv stadfesta, og det er heile verdien.

Eit videresendingsfelt er metadata om ei kjede. X-Forwarded-For, X-Real-IP og det standardiserte feltet Forwarded kan skrivast av kvar klient som når eit endepunkt som speglar dei, så pålitelegheita deira heng heilt på kven som fekk lov til å setje dei.

Hald begge i førespurnadskonteksten under ulike namn. Ein applikasjon som skriv over peeren med headeren, misser evna til å rekonstruere ein tillitsfeil seinare, og det er nettopp då du treng han.

Ein header omdirigerer aldri sambandet

Å skrive ei adresse i eit videresendingsfelt endrar ikkje kjelda til TCP-sambandet som kjem til serveren, og det endrar ikkje rutinga nokon stad langs stien. Vanleg VPN-ruting eller kjelde-NAT leverer trafikk heilt utan nokon HTTP-header. På same måte skriv ein transittgateway ikkje om ei rett verna HTTPS-utveksling utan å endre arrangementet for TLS-endepunktet.

Den motsette feilen er like vanleg: HTTPS gjer ikkje ein klientlevert videresendt header sann. Det verner transporten av ein falsk påstand like godt som av ein sann.

Viss ein kollega føreslår ei headerendring for å løyse eit ruteproblem, har diagnosen allereie gått gale. Reparer stien, eller reparer proxykonfigurasjonen som skriv headeren.

Namngi proxyen som har lov til å hevde

To reglar gjer eit videresendingsfelt brukbart, og begge er konfigurasjon og ikkje kode. Kasten normaliserer eller kastar alt som kjem utanfrå, etter si eiga dokumenterte åtferd for desse felta. Deretter tek opphavet ei erstatningsadresse frå proxystien du namngav, og ikkje frå noko anna. Den andre regelen gjeld berre så lenge klientar ikkje kan nå opphavet på annan måte, fordi eit opphav som svarar på både direkte og proxyde førespurnader, veit ikkje kva av dei han tener.

NGINX-modulen for ekte IP viser delinga tydeleg. set_real_ip_from namngir avsendarane kvars påstand tel, og real_ip_header seier kva felt som ber han; den første utfører tilliten, den andre seier berre kvar ein skal sjå.

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

Eit headerutvaldirektiv aleine fastslår framleis ingenting om kven som sende verdien.

Transporttryggleik må gå heile vegen mellom komponentane du stolar på. Ein kant som normaliserer rett, misser den verdien i det augneblikket eit uverna hopp lenger nede lèt nokon andre redigere påstanden medan han reiser.

Handter kjeder med fleire hopp medvite

Fleire proxyar krev ein eksplisitt kjedemodell. Ikkje ta den venstre eller høgre kommaseparerte verdien fordi eit blogginnlegg gjorde det; finn ut kva av proxyane dine som legg til, kva som erstattar og kva som bevarer det innkomande feltet. NGINX kan til dømes gå lista baklengs gjennom det betra setet sitt og stoppe ved den første adressa han ikkje eig, og det er regelen til den produktet, ikkje ei lov som kvart rammeverk følgjer. Les dokumentasjonen til din eigen proxy med dei same to spørsmåla: kva verdi vel han, og kva avsendarar trur han på?

Skriv ned kjeda: hopprekkjefølgje, kva hopp som set feltet, og kva hopp som fjernar innkomande kopiar. Hald deretter notatet ved sida av proxykonfigurasjonen, ikkje berre i billetten. Test det deretter ved å sende ein førespurnad med ein forfalska header gjennom den godkjende valideringsprosessen og stadfeste at opphavet ignorerer han.

Når du legg til eit hopp, gå gjennom det dokumentet. Ein ny lastbalansar sett inn framfor den betra proxyen, kan endre kva adresse som vinn utan at nokon redigerer applikasjonen.

Hald båe observasjonane i loggen

Der diagnostikk er tillaten, logg peeren til sambandet og den normaliserte klientadressa som to separate felt, og legg berre til dei videresendingsmetadata som føremålet faktisk treng. Prov deretter utrullinga med to førespurnader: ein via proxyen som bør registrere båe verdiane fornuftig, og eit forsøk direkte til opphavet som må avvisast.

Hugs kva paret tyder. Headarar legg til kontekst frå ein komponent du valde å stole på; peeren blir verande den einaste adressa verten din faktisk såg. Ingen av dei er prov for individuell identitet, og eit design som behandlar ein av dei som prov, vil ta feil om nokon.