Soketin vastapää vai välitetty otsake: kumpaan osoitteeseen luottaa?

Sovellukseesi saapuva pyyntö kantaa kahdenlaisia osoitetodisteita: vastapää, joka avasi verkkoyhteyden, ja HTTP-kenttä, joka väittää aiemman asiakkaan osoitetta. Ne vastaavat eri kysymyksiin. Soketin vastapäätä havainnoidaan, kun taas otsakkeen väittää se, joka sen kirjoitti, eikä kumpikaan saisi hiljaisesti korvata toista lokissa tai pääsysäännössä. Alla oleva vertailu pitää ne erillään ja näyttää sitten ainoan järjestelyn, jossa otsakkeesta tulee käyttökelpoinen.

Kuvaile polku ennen kuin vertaile mitään:

Client -> approved reverse proxy -> application origin

Tässä järjestelyssä alkuperän soketin vastapää on tavallisesti välityspalvelin, ja välitysotsake voi kantaa välityspalvelimen väitteen asiakkaasta. Sen arvo tulee hallitusta suhteesta tuohon välityspalvelimeen, ei otsakkeen nimestä.

Kahdenlaisia osoitetodisteita

Soketin vastapää on tosiasia yhdestä TCP-yhteydestä: jokin suoritti kättelyn loppuun tuosta osoitteesta. Se ei välttämättä ole se ihminen, laite tai tili, josta välität, koska VPN tai Tor-poistumissolmu voi laillisesti olla lähde, jota palvelu havainnoi. Se on silti ainoa osoite, jonka isäntä itse vahvisti, ja siinä on koko sen arvo.

Välityskenttä on metatietoa ketjusta. X-Forwarded-For, X-Real-IP ja standardoitu kenttä Forwarded voi olla minkä tahansa sellaisen asiakkaan kirjoittama, joka saavuttaa päätepisteen, joka toistaa ne, joten niiden luotettavuus riippuu täysin siitä, kenelle niiden asettaminen sallittiin.

Pidä molemmat pyynnön kontekstissa eri nimillä. Sovellus, joka korvaa vastapään otsakkeella, menettää kyvyn jäljittää luottamusvirhe myöhemmin, ja juuri silloin sitä tarvitset.

Otsake ei koskaan uudelleenohjaa yhteyttä

Osoitteen kirjoittaminen välityskenttään ei muuta palvelimelle saapuvan TCP-yhteyden lähdettä eikä muuta reititystä missään polun kohdassa. Tavallinen VPN-reititys tai lähde-NAT toimittaa liikennettä ilman yhtään HTTP-otsaketta. Samoin läpikulkupääte ei kirjoita uudelleen asianmukaisesti suojattua HTTPS-vaihtoa muuttamatta TLS-päätepisteen järjestelyä.

Päinvastainen virhe on yhtä yleinen: HTTPS ei tee asiakkaan toimittamasta välitysotsakkeesta totta. Se suojaa väärän väitteen siirron täsmälleen yhtä hyvin kuin toden.

Jos kollega ehdottaa otsakkeen muuttamista reititysongelman korjaamiseksi, diagnoosi on jo mennyt pieleen. Korjaa polku tai korjaa välityspalvelimen kokoonpano, joka kirjoittaa otsakkeen.

Nimeä välityspalvelin, jolla on lupa väittää

Kaksi sääntöä tekevät välityskentästä käyttökelpoisen, ja molemmat ovat kokoonpanoa eivätkä koodia. Reuna normalisoi tai pudottaa kaiken ulkopuolelta tulevan omien dokumentoitujen käytäntöjensä mukaisesti näiden kenttien osalta. Sen jälkeen alkuperä ottaa korvaavan osoitteen nimeämältäsi välityspolulta eikä mistään muualta. Toinen sääntö pätee vain niin kauan kuin asiakkaat eivät voi saavuttaa alkuperää muulla tavoin, koska alkuperä, joka vastaa sekä suoriin että välitettyihin pyyntöihin, ei tiedä, kumpaa se palvelee.

NGINXin todellisen IP:n moduuli näyttää jaon selvästi. set_real_ip_from nimeää lähettäjät, joiden väite lasketaan, ja real_ip_header kertoo, mikä kenttä sen kantaa; ensimmäinen tekee luottamisen, toinen vain kertoo, mistä katsoa.

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

Pelkkä otsakkeen valintadirektiivi ei vielä vahvista mitään siitä, kuka arvon lähetti.

Siirtoturvallisuuden on kuljettava koko matka luottamiesi komponenttien välillä. Reuna, joka normalisoi oikein, menettää tämän arvon heti, kun suojaamaton hyppy alempana päästää jonkun muun muokkaamaan väitettä sen matkatessa.

Käsittele monen hypyn ketjuja tietoisesti

Useat välityspalvelimet tarvitsevat selkeän ketjumallin. Älä ota vasemman- tai oikeanpuolimmaista pilkulla erotettua arvoa siksi, että jokin blogikirjoitus teki niin; selvitä, mikä välityspalvelimistasi lisää, mikä korvaa ja mikä säilyttää saapuvan kentän. NGINX voi esimerkiksi käydä listaa taaksepäin luotettua joukkoaan vasten ja pysähtyä ensimmäiseen osoitteeseen, jota se ei omista, ja se on tuon tuotteen sääntö eikä laki, jota jokainen kehys noudattaa. Lue oman välityspalvelimesi dokumentaatio samoin kahdella kysymyksellä: minkä arvon se valitsee ja keihin lähettäjiin se uskoo?

Kirjoita ketju muistiin: hyppyjen järjestys, mikä hyppy asettaa kentän ja mikä hyppy poistaa saapuvat kopiot. Pidä sitten muistiinpano välityspalvelimen kokoonpanon vieressä, ei vain tiketissä. Testaa se sitten lähettämällä pyyntö väärennetyllä otsakkeella hyväksytyn vahvistusprosessin läpi ja vahvistamalla, että alkuperä jättää sen huomiotta.

Kun lisäät hypyn, käy tuo asiakirja uudelleen läpi. Luotetun välityspalvelimen eteen lisätty uusi kuormantasain voi muuttaa sitä, mikä osoite voittaa, ilman että kukaan muokkaa sovellusta.

Pidä molemmat havainnot lokissa

Missä diagnostiikka on sallittua, kirjaa yhteyden vastapää ja normalisoitu asiakasosoite kahtena erillisenä kenttänä ja lisää vain ne välitystiedot, joita tarkoitus todella tarvitsee. Todista sitten käyttöönotto kahdella pyynnöllä: yksi välityspalvelimen kautta, jonka pitäisi kirjata molemmat arvot järkevästi, ja yksi yritys suoraan alkuperään, joka on hylättävä.

Muista, mitä pari tarkoittaa. Otsake lisää kontekstia, jonka tarjoaa komponentti, jonka valitsit luottaa; vastapää on edelleen ainoa osoite, jonka isäntäsi todella näki. Kumpikaan ei ole todiste yksilöllisestä identiteetistä, ja suunnittelu, joka pitää kumpaa tahansa todisteena, erehtyy jonkun kohdalla.