Soketi vastaspool versus edastatud päis: millist aadressi usaldada?

Teie rakendusse saabuv päring kannab kahte tüüpi aadressitõendeid: vastaspool, mis avas võrguühenduse, ja HTTP-väli, mis väidab varasema kliendi aadressi. Need vastavad erinevatele küsimustele. Soketi vastaspoolt vaadeldakse, päist aga väidab see, kes selle kirjutas, ja kumbki ei tohiks logis ega juurdepääsureeglis teist vaikselt asendada. Allpool olev võrdlus hoiab need lahus ja näitab seejärel ainsat korraldust, milles päis muutub kasutatavaks.

Kirjeldage teed enne, kui midagi võrdlete:

Client -> approved reverse proxy -> application origin

Selles korralduses on päritoluserva soketi vastaspool tavaliselt puhverserver ja edastuspäis võib kanda puhverserveri väidet kliendi kohta. Selle väärtus tuleb kontrollitud suhtest selle puhverserveriga, mitte päise nimest.

Kahte tüüpi aadressitõendid

Soketi vastaspool on fakt ühe TCP-ühenduse kohta: miski lõpetas sellest aadressist kätlemise. See ei ole tingimata inimene, seade ega konto, millest hoolite, sest VPN või Tor-i väljund võib seaduslikult olla allikas, mida teenus vaatleb. See on siiski ainus aadress, mille host ise kinnitas, ja selles on kogu selle väärtus.

Edastusväli on metaandmed ahela kohta. X-Forwarded-For, X-Real-IP ja standardiseeritud väli Forwarded võib olla kirjutatud iga kliendi poolt, kes jõuab lõpp-punkti, mis neid kordab, seega sõltub nende usaldusväärsus täielikult sellest, kellel oli lubatud neid seada.

Hoidke mõlemat päringu kontekstis eri nimede all. Rakendus, mis kirjutab vastaspool päisega üle, kaotab hiljem usaldusvea rekonstrueerimise võime, ja just siis on seda vaja.

Päis ei suuna ühendust kunagi ümber

Aadressi kirjutamine edastusväljale ei muuda serverisse saabuva TCP-ühenduse allikat ega muuda marsruutimist mitte kuskil teel. Tavaline VPN-marsruutimine või lähtevõrgu NAT toimetab liiklust ilma ühegi HTTP-päiseta. Samuti ei kirjuta transiitlüüs korralikult kaitstud HTTPS-vahetust ümber ilma TLS-i lõpp-punkti korraldust muutmata.

Vastupidine viga on sama tavaline: HTTPS ei muuda kliendi esitatud edastuspäist tõeseks. See kaitseb vale väite transporti täpselt sama hästi kui tõese oma.

Kui kolleeg pakub marsruutimisprobleemi parandamiseks päise muutmist, on diagnoos juba viltu läinud. Parandage tee või parandage puhverserveri konfiguratsioon, mis päise kirjutab.

Nimetage puhverserver, millel on lubatud väita

Kaks reeglit teevad edastusvälja kasutatavaks ja mõlemad on konfiguratsioon, mitte kood. Serv moodustab või jätab kõrvale kõik väljast saabuva vastavalt oma dokumenteeritud käitumisele nende väljade puhul. Seejärel võtab päritolu asendusaadressi teie nimetatud puhverserveri teelt ja mitte mujalt. Teine reegel kehtib ainult seni, kuni kliendid ei saa päritolu muul viisil kätte, sest päritolu, mis vastab nii otsestele kui puhverserveri kaudu tulevatele päringutele, ei tea, kumba neist ta teenindab.

NGINX-i reaalse IP moodul näitab jaotust selgelt. set_real_ip_from nimetab saatjad, kelle väide loeb, ja real_ip_header ütleb, milline väli seda kannab; esimene teostab usalduse, teine ütleb ainult, kuhu vaadata.

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

Üksi päise valiku direktiiv ei tuvasta veel midagi selle kohta, kes väärtuse saatis.

Transporditurvalisus peab kulgema kogu tee teie usaldatavate komponentide vahel. Serv, mis õigesti normaliseerib, kaotab selle väärtuse hetkel, mil allpool olev kaitsmata hüpe laseb kellelgi teisel väidet teel muuta.

Käsitlege mitme hüppega ahelaid teadlikult

Mitu puhverserverit nõuavad selget ahela mudelit. Ärge võtke kõige vasakpoolsemat või parempoolsemat komadega eraldatud väärtust sellepärast, et mõni blogipostitus nii tegi; uurige, milline teie puhverserveritest lisab, milline asendab ja milline säilitab sissetuleva välja. Näiteks NGINX võib nimekirja tagurpidi läbi oma usaldatud hulga käia ja peatuda esimesel aadressil, mida ta ei oma, ja see on selle toote reegel, mitte seadus, mida iga raamistik järgib. Lugege oma puhverserveri dokumentatsiooni samade kahe küsimusega: millise väärtuse see valib ja milliseid saatjaid see usub?

Kirjutage ahel üles: hüpete järjekord, milline hüpe seab välja ja milline hüpe eemaldab sissetulevad koopiad. Seejärel hoidke seda märkust puhverserveri konfiguratsiooni kõrval, mitte ainult piletil. Seejärel testige seda, saates võltsitud päisega päringu heakskiidetud valideerimisprotsessi kaudu ja kinnitades, et päritolu eirab seda.

Kui lisate hüppe, vaadake see dokument uuesti läbi. Usaldatava puhverserveri ette lisatud uus koormusjaotur võib muuta, milline aadress võidab, ilma et keegi rakendust muudaks.

Hoidke mõlemad vaatlused logis

Kus diagnostika on lubatud, logige ühenduse vastaspool ja normaliseeritud kliendi aadress kahe eraldi väljana ning lisage ainult need edastusmetaandmed, mida eesmärk tõesti vajab. Seejärel tõestage juurutus kahe päringuga: üks puhverserveri kaudu, mis peaks mõistlikult kirja panema mõlemad väärtused, ja üks otsene katse päritolu vastu, mis tuleb tagasi lükata.

Pidage meeles, mida see paar tähendab. Päis lisab konteksti, mille annab komponent, mille te usaldada valisite; vastaspool jääb ainsaks aadressiks, mida teie host tegelikult nägi. Kumbki ei ole üksikisiku identiteedi tõend, ja kujundus, mis kohtleb kumbagi tõendina, eksib kellegi suhtes.