Soket-kidea edo birbidalitako goiburua: zein helbideri konfiantza eman?

Zure aplikaziora iristen den eskaera batek bi helbide-froga mota daramatza: sare-konexioa ireki zuen kidea eta lehenagoko bezero baten helbidea dioen HTTP eremu bat. Galdera ezberdinei erantzuten diete. Soket-kidea behatua da, eta goiburua idatzi zuenak dioena da, eta batek ez luke bestea isilka ordezkatu behar erregistro batean edo sarbide-arau batean. Beheko konparazioak bereizten ditu, eta gero goiburua erabilgarri bihurtzen den antolamendu bakarra erakusten du.

Deskribatu bidea ezer konparatu aurretik:

Client -> approved reverse proxy -> application origin

Antolamendu horretan jatorriaren soket-kidea proxy-a izan ohi da, eta birbidaltze-goiburu batek proxy-ak bezeroari buruzko duen baieztapena eraman dezake. Bere balioa proxy horrekin duzun harreman kontrolatutik dator, ez goiburuaren izenetik.

Bi helbide-froga mota

Soket-kidea TCP konexio bati buruzko egitatea da: zerbait helbide hartatik eskua ematera iritsi zen. Ez da nahitaez axola zaizun pertsona, gailua edo kontua, VPN bat edo Tor irteera bat zerbitzu batek behatzen duen iturria izan baitezake legez. Hala ere, ostalariak berak egiaztatu zuen helbide bakarra da, eta horixe da haren balio osoa.

Birbidaltze-eremua kate bati buruzko metadatuak dira. X-Forwarded-For, X-Real-IP eta estandarizatutako eremu Forwarded haiek oihartzuna egiten duen helmuga batera iristen den edozein bezerok idatz dezake, beraz haien fidagarritasuna erabat haiek ezartzea nork lortu zuen araberakoa da.

Eduki itzazu biak eskaeraren testuinguruan izen ezberdinekin. Kidea goiburuarekin gainidazten duen aplikazioak konfiantza-errore bat berreraikitzeko gaitasuna galtzen du, eta hori da hain zuzen harekin behar duzun unea.

Goiburu batek ez du inoiz konexioa berbideratzen

Helbide bat birbidaltze-eremu batean idazteak ez du zerbitzarira iristen den TCP konexioaren iturria aldatzen, ezta bideko inongo lekuan bideratzea ere. Ohiko VPN bideratzeak edo jatorrizko NAT-ak trafikoa HTTP goiburu bat ere gabe entrega dezakete. Era berean, trantsizio-pasabideak ez du ondo babestutako HTTPS trukea berridazten TLS helmugaren antolamendua aldatu gabe.

Alderantzizko akatsa bezain ohikoa da: HTTPS-ek ez du bezeroak emandako birbidaltze-goiburua egiazkoa bihurtzen. Baieztapen faltsu baten garraioa babesten du, egiazko baten antzeko sendotasunez.

Lankide batek goiburua aldatzea proposatzen badu bideratze-arazo bat konpontzeko, diagnostikoa jadanik oker doa. Konpondu bidea edo konpondu goiburua idazten duen proxy-aren konfigurazioa.

Izendatu baieztatzeko baimena duen proxy-a

Bi arulek egiten dute birbidaltze-eremua erabilgarri, eta biak konfigurazioa dira, ez kodea. Ertzak kanpotik iristen dena normalizatzen edo botatzen du, eremu horietarako dituen jokabide dokumentatuaren arabera. Gero jatorriak ordezko helbide bat hartzen du izendatu duzun proxy bide horretatik eta ez beste inondik. Bigarren arau hori bezeroek jatorrira beste modu batera iritsi ezin duten bitartean baino ez da baliozkoa, zuzenezko zein proxy bidezko eskaerei erantzuten dien jatorri batek ez baitaki zeini ari zaion zerbitzatzen.

NGINX-ren benetako IP modulua argi erakusten du banaketa. set_real_ip_from dio zein igorleren baieztapena zenbatzen den, eta real_ip_header zein eremuk eramaten duen esaten du; lehenengoak konfiantza egiten du, bigarrenak begiratu beharreko lekua baino ez du esaten.

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

Goiburu hautatzeko direktiba batek, bere horretan, ez du oraindik ezer ezartzen balioa norbaitek bidali zuenari buruz.

Garraio-segurtasunak zure konfiantzazko osagaien arteko bide osoa egin behar du. Modu egokian normalizatzen duen ertzak balio hori galtzen du beheko jauzi babesgabe batek baieztapena bidaiatzen ari den bitartean norbaiti editatzen uzten dion unean.

Kudeatu hainbat jauzitako kateak jakinaren gainean

Proxy anitzek kate-eredu esplizitua behar dute. Ez hartu komaz bereizitako balio ezkerrenekoa edo eskuinekoa blog-sarrera batek hala egin zuelako; jakin itzazu zure proxyetatik zein gehitzen duen, zein ordezkatzen duen eta zein gordetzen duen sarrerako eremua. NGINX-ek, adibidez, zerrenda atzerantz zeharka dezake bere konfiantzazko multzoaren aurka eta ez duen lehen helbidean geldi daiteke, eta hori produktu horren araua da, eta ez framework bakoitzak jarraitzen duen legea. Irakurri zure proxy-aren dokumentazioa bi galdera berberekin: zein balio hautatzen du eta zein igorlerek sinesten du?

Idatzi katea: jauzien ordena, zein jauzik ezartzen duen eremua eta zein jauzik kentzen dituen sarrerako kopiak. Ondoren, eduki ohar hori proxyaren konfigurazioaren ondoan, ez txartelean soilik. Ondoren probatu hura baimendutako balidazio-prozesutik goiburu faltsu bat duen eskaera bat bidaliz eta jatorriak hura ez duela kontuan hartzen baieztatuz.

Jauzi bat gehitzen duzunean, berrikusi dokumentu hori. Konfiantzazko proxyaren aurrean txertatutako karga-banatzaile berri batek zein helbidek irabazten duen alda dezake inork aplikazioa editatu gabe.

Eduki bi behaketak erregistroan

Diagnostikoa baimenduta dagoen lekuan, erregistratu konexioaren kidea eta normalizatutako bezeroaren helbidea bi eremu bereizi gisa, eta gehitu helburuak benetan behar dituen birbidaltze-metadatuak soilik. Ondoren frogatu inplementazioa bi eskaerekin: proxy bidezko bat, bi balioak zentzuz erregistratu beharko lituzkeena, eta jatorrira zuzenean egindako saiakera bat, ukatua izan behar dena.

Gogoratu zer esan nahi duen bikoteak. Goiburuak konfiantza ematea aukeratu duzun osagai batek emandako testuingurua gehitzen du; kidea zure ostalariak benetan ikusi zuen helbide bakarra izaten jarraitzen du. Biak ez dira norbanakoaren identitatearen froga, eta edozein froga gisa hartzen duen diseinuak norbaiti buruz huts egingo du.