Partneri i socket-it apo header-i i përcjellë: cilës adresë t'i besosh?

Një kërkesë që mbërrin në aplikacionin tuaj mbart dy lloje provash për adresën: partnerin që hapi lidhjen e rrjetit dhe një fushë HTTP që pretendon adresën e një klienti të mëparshëm. Ato u përgjigjen pyetjeve të ndryshme. Partneri i socket-it vëzhgohet, ndërsa header-i pretendohet nga ai që e shkroi, dhe asnjëra nuk duhet të zëvendësojë qetësisht tjetrën në një log ose në një rregull aksesi. Krahasimi më poshtë i mban të ndara dhe më pas tregon rregullimin e vetëm në të cilin header-i bëhet i përdorshëm.

Përshkruani rrugën para se të krahasoni çdo gjë:

Client -> approved reverse proxy -> application origin

Në atë rregullim partneri i socket-it i burimit është zakonisht proxy-i, dhe një header përcjelljeje mund të mbartë pretendimin e proxy-it për klientin. Vlera e tij vjen nga marrëdhënia e kontrolluar me atë proxy, jo nga emri i header-it.

Dy lloje provash për adresën

Partneri i socket-it është një fakt për një lidhje të vetme TCP: diçka përfundoi një shtrëngim duarsh nga ajo adresë. Nuk është domosdoshmërisht njeriu, pajisja ose llogaria për të cilën ju interesoheni, sepse një VPN ose një dalje Tor mund të jenë ligjërisht burimi që vëzhgon një shërbim. Megjithatë mbetet adresa e vetme që vetë host-i verifikoi, dhe në këtë qëndron e gjithë vlera e tij.

Një fushë përcjelljeje është metadata për një zinxhir. X-Forwarded-For, X-Real-IP dhe fusha e standardizuar Forwarded mund të shkruhen nga çdo klient që arrin një pikë fundore që i pasqyron, kështu që besueshmëria e tyre varet plotësisht nga kush u lejua t'i vendosë.

Mbajini të dyja në kontekstin e kërkesës nën emra të veçantë. Një aplikacion që mbishkruan partnerin me header-in humbet aftësinë për të rindërtuar më vonë një gabim besimi, dhe ky është pikërisht momenti kur ju nevojitet.

Një header nuk e ridrejton kurrë lidhjen

Shkrimi i një adrese në një fushë përcjelljeje nuk ndryshon burimin e lidhjes TCP që mbërrin në server dhe nuk ndryshon rrugëtimin askund përgjatë rrugës. Rrugëtimi i zakonshëm i VPN-së ose NAT burimor dërgon trafikun pa asnjë header HTTP. Po ashtu, një portë tranziti nuk rishkruan një shkëmbim HTTPS të mbrojtur siç duhet pa ndryshuar rregullimin e pikës fundore TLS.

Gabimi i kundërt është po aq i zakonshëm: HTTPS nuk e bën të vërtetë një header përcjelljeje të dhënë nga klienti. Ai mbron transportin e një pretendimi të rremë po aq mirë sa të një të vërtetë.

Nëse një koleg propozon një ndryshim header-i për të rregulluar një problem rrugëtimi, diagnoza tashmë ka shkuar keq. Rregulloni rrugën, ose rregulloni konfigurimin e proxy-it që shkruan header-in.

Emërtoni proxy-in që lejohet të pretendojë

Dy rregulla e bëjnë një fushë përcjelljeje të përdorshme, dhe të dyja janë konfigurim dhe jo kod. Buza normalizon ose hedh poshtë gjithçka që vjen nga jashtë, sipas sjelljes së vetë dokumentuar për ato fusha. Më pas burimi merr një adresë zëvendësuese nga rruga e proxy-it që emërtuat dhe nga asgjë tjetër. Rregulli i dytë vlen vetëm për sa kohë klientët nuk mund ta arrijnë burimin në një mënyrë tjetër, sepse një burim që përgjigjet si për kërkesat e drejtpërdrejta ashtu edhe për ato përmes proxy-it nuk e di se cilës prej tyre po i shërben.

Moduli i IP-së reale i NGINX e tregon ndarjen qartë. set_real_ip_from emërton dërguesit, pretendimi i të cilëve llogaritet, dhe real_ip_header thotë se cila fushë e mban atë; i pari kryen besimin, i dyti thotë vetëm ku të shikosh.

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

Një direktivë e zgjedhjes së header-it më vete ende nuk vërteton asgjë për atë se kush e dërgoi vlerën.

Siguria e transportit duhet të kalojë gjithë rrugën midis komponentëve që ju besoni. Një buzë që normalizon saktë e humb atë vlerë në momentin kur një kërcim i pambrojtur më poshtë lejon dikë tjetër ta redaktojë pretendimin ndërsa është në rrugë.

Trajtoni me vetëdije zinxhirët me shumë kërcime

Disa proxy kërkojnë një model të qartë zinxhiri. Mos merrni vlerën më të majtë ose më të djathtë të ndarë me presje sepse kështu bëri ndonjë postim blogu; zbuloni cili prej proxy-ve tuaj shtojnë, cili zëvendëson dhe cili ruan fushën hyrëse. NGINX, për shembull, mund ta përshkojë listën mbrapsht kundrejt grupit të vet të besuar dhe të ndalet në adresën e parë që nuk e zotëron, dhe ky është rregulli i atij produkti, jo një ligj që ndjek çdo kornizë. Lexoni dokumentacionin e proxy-it tuaj me të njëjtat dy pyetje: cilën vlerë zgjedh dhe cilëve dërgues u beson?

Shkruani zinxhirin: rendi i kërcimeve, cili kërcim e vendos fushën dhe cili kërcim i heq kopjet hyrëse. Më pas mbajeni atë shënim pranë konfigurimit të proxy-it, jo vetëm në tiketë. Më pas testojeni duke dërguar një kërkesë me header të falsifikuar përmes procesit të miratuar të validimit dhe duke konfirmuar se burimi e injoron atë.

Kur shtoni një kërcim, rishikoni atë dokument. Një balancues i ri ngarkese i futur përpara proxy-it të besuar mund të ndryshojë cila adresë fiton pa redaktuar askush aplikacionin.

Mbajini të dyja vëzhgimet në log

Aty ku diagnostikimi është i autorizuar, regjistroni partnerin e lidhjes dhe adresën e klientit të normalizuar si dy fusha të veçanta, dhe shtoni vetëm metadata e përcjelljes që qëllimi ka vërtet nevojë. Më pas provoni vendosjen me dy kërkesa: një përmes proxy-it që duhet t'i regjistrojë të dyja vlerat në mënyrë të arsyeshme, dhe një përpjekje të drejtpërdrejtë drejt burimit që duhet të refuzohet.

Mbani mend çfarë do të thotë çifti. Header-i shton kontekst të siguruar nga një komponent që zgjodhët t'i besoni; partneri mbetet adresa e vetme që host-i juaj pa vërtet. Asnjëra nuk është provë e identitetit individual, dhe një dizajn që trajton ndonjë prej tyre si provë do të gabojë për dikë.