Sokkarfélagi eða framsendur haus: hvaða vistfang á að treysta?
Sokkarfélaginn og framsendur haus eru mismunandi sönnunargögn. Berið saman hvað hvort sannar, og treystið hausnum aðeins í gegnum milliþjónakeðju sem þið stjórnið.
Beiðni sem berst forritinu þínu ber tvenns konar sönnun um vistfang: jafningjann sem opnaði nettenginguna, og HTTP-svið sem heldur fram vistfangi fyrri biðils. Þau svara mismunandi spurningum. Jafninginn er áhorfður, en hausnum heldur fram sá sem skrifaði hann, og hvorugt ætti að koma hljóðlaust í stað hins í annál eða aðgangsreglu. Samanburðurinn hér að neðan heldur þeim aðskildum og sýnir svo eina fyrirkomulagið þar sem hausinn verður nothæfur.
Lýsið leiðinni áður en þið berið saman hvað sem er:
Client -> approved reverse proxy -> application originÍ því fyrirkomulagi er jafningi upprunans yfirleitt milliþjónninn, og framsendingarhaus getur borið fullyrðingu milliþjónsins um biðilinn. Gildi hans kemur frá stýrðu sambandinu við þann milliþjón, ekki frá nafni haussins.
Tvenns konar sönnun um vistfang
Jafninginn er staðreynd um eina TCP-tengingu: eitthvað lauk handabandi frá því vistfangi. Það er ekki endilega manneskjan, tækið eða reikningurinn sem þér þykir vænt um, því VPN eða Tor-útgangur geta löglega verið uppsprettan sem þjónusta fylgist með. Það er samt eina vistfangið sem hýsillinn sjálfur staðfesti, og í því felst allt gildi þess.
Framsendingarsvið er lýsigögn um keðju. X-Forwarded-For, X-Real-IP og staðlaða sviðið Forwarded getur hver sem er biðill skrifað sem nær endapunkti sem endurómar þau, svo áreiðanleiki þeirra fer algjörlega eftir því hverjum var leyft að setja þau.
Haldið báðum í samhengi beiðninnar undir aðskildum nöfnum. Forrit sem yfirskrifar jafningjann með hausnum missir getuna til að endurgera traustsvillu síðar, og það er einmitt þegar þú þarft á henni að halda.
Haus leiðir tenginguna aldrei annað
Að skrifa vistfang í framsendingarsvið breytir ekki uppruna TCP-tengingarinnar sem berst netþjóninum, og breytir ekki leiðsögn neins staðar á leiðinni. Venjuleg VPN-leiðsögn eða upprunanetþýðing skilar umferð án nokkurs HTTP-hauss. Á sama hátt endurskrifar gátt ekki rétt varið HTTPS-skipti án þess að breyta fyrirkomulagi TLS-endapunktsins.
Andstæða mistökin eru jafn algeng: HTTPS gerir framsendingarhaus sem biðillinn leggur til ekki sannan. Það verndar flutning rangrar fullyrðingar jafn vel og réttrar.
Ef kollegi stingur upp á hausbreytingu til að laga leiðsagnarvandamál hefur greiningin þegar farið úrskeiðis. Lagaðu leiðina, eða lagaðu stillingar milliþjónsins sem skrifar hausinn.
Nefnið milliþjóninn sem má fullyrða
Tvær reglur gera framsendingarsvið nothæft, og báðar eru stillingar en ekki kóði. Brúnin venjuleguðu eða hendir öllu sem kemur að utan, samkvæmt eigin skjalfestu hegðun fyrir þau svið. Síðan tekur uppruninn staðgengilsvistfang af milliþjónsleiðinni sem þú nefndir og hvergi annars staðar. Önnur reglan gildir aðeins á meðan biðlarar komast ekki að upprunanum á annan hátt, því uppruni sem svarar bæði beinum og millifærðum beiðnum veit ekki hvorum hann þjónar.
NGINX einingin fyrir raunverulegt IP sýnir skiptinguna skýrt. set_real_ip_from nefnir sendendurna sem fullyrðing þeirra telur, og real_ip_header segir hvaða svið ber hana; hið fyrra framkvæmir traustið, hið síðara segir aðeins hvar á að horfa.
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
Hausvalsfyrirmæli ein og sér staðfesta enn ekkert um hver sendi gildið.
Flutningsöryggi verður að ganga alla leið milli eininganna sem þú treystir. Brún sem venjulegast rétt missir það gildi á þeirri stundu sem óvarið stökk neðar leyfir einhverjum öðrum að breyta fullyrðingunni á meðan hún fer.
Farið með keðjur með mörgum stökkum af ásetningi
Nokkrir milliþjónar þurfa skýrt keðjulíkan. Takið ekki vinstra eða hægra gildið aðskilið með kommum því einhver bloggfærsla gerði það; komið í ljós hvaða milliþjónar bæta við, hverjir koma í staðinn og hverjir varðveita innkomandi sviðið. NGINX getur til dæmis gengið listann aftur á bak gegn treysta safni sínu og stöðvast við fyrsta vistfangið sem það á ekki, og það er regla þeirrar vöru, ekki lög sem hver rammi fylgir. Lestu skjöl eigin milliþjóns með sömu tveimur spurningum: hvaða gildi velur hann, og hvaða sendendum trúir hann?
Skrifið keðjuna niður: stökksröð, hvaða stökk setur sviðið og hvaða stökk fjarlægir innkomandi afrit. Haldið svo þeirri athugasemd við hlið milliþjónsstillinganna, ekki bara í miðanum. Prófið hana svo með því að senda beiðni með fölsuðum haus í gegnum samþykkt staðfestingarferli og staðfesta að uppruninn hunsar hana.
Þegar þið bætið við stökki skuluð þið endurskoða það skjal. Nýr álagsdreifir fyrir framan treysta milliþjóninn getur breytt því hvaða vistfang vinnur án þess að nokkur breyti forritinu.
Haldið báðum athugunum í annálnum
Þar sem greining er heimiluð skuluð þið skrá jafningja tengingarinnar og venjulega biðilvistfangið sem tvö aðskilin svið, og bæta aðeins við þeim framsendingarlýsigögnum sem tilgangurinn þarfnast í raun. Sannið svo uppsetninguna með tveimur beiðnum: einni í gegnum milliþjón sem ætti að skrá bæði gildin skynsamlega, og einni beinni tilraun að upprunanum sem á að hafna.
Munið hvað parið þýðir. Hausinn bætir við samhengi sem eining sem þið völduð að treysta leggur til; jafninginn er áfram eina vistfangið sem hýsillinn þinn sá í raun. Hvorugt er sönnun um einstaklingsauðkenni, og hönnun sem meðhöndlar hvort sem er sem sönnun mun hafa rangt fyrir sér um einhvern.