Protipól soketu alebo preposielaná hlavička: ktorej adrese dôverovať?

Požiadavka, ktorá prichádza do vašej aplikácie, nesie dva druhy dôkazov o adrese: protipól, ktorý otvoril sieťové spojenie, a pole HTTP, ktoré tvrdí adresu skoršieho klienta. Odpovedajú na rôzne otázky. Protipól soketu sa pozoruje, kým hlavičku tvrdí ten, kto ju napísal, a ani jedno by nemalo potichu nahradiť druhé v zázname alebo v pravidle prístupu. Porovnanie nižšie ich drží oddelene a potom ukazuje jediné usporiadanie, v ktorom sa hlavička stane použiteľnou.

Opíšte cestu, skôr než čokoľvek porovnáte:

Client -> approved reverse proxy -> application origin

V tomto usporiadaní je protipól soketu na strane pôvodu zvyčajne proxy a preposielacia hlavička môže niesť tvrdenie proxy o klientovi. Jej hodnota pochádza z riadeného vzťahu s touto proxy, nie z názvu hlavičky.

Dva druhy dôkazov o adrese

Protipól soketu je fakt o jednom TCP spojení: niečo dokončilo nadviazanie spojenia z tejto adresy. Nemusí to byť človek, zariadenie ani účet, na ktorom vám záleží, pretože VPN alebo výstupný uzol Tor môžu byť legitímne zdrojom, ktorý služba pozoruje. Napriek tomu je to jediná adresa, ktorú overil samotný hostiteľ, a v tom je celá jej hodnota.

Pole preposielania sú metadáta o reťazci. X-Forwarded-For, X-Real-IP a štandardizované pole Forwarded môže napísať každý klient, ktorý dosiahne koncový bod, ktorý ich vracia, takže ich dôveryhodnosť úplne závisí od toho, komu bolo dovolené ich nastaviť.

Uchovávajte oboje v kontexte požiadavky pod odlišnými názvami. Aplikácia, ktorá prepíše protipól hlavičkou, stráca schopnosť neskôr rekonštruovať chybu dôvery, a to je práve ten okamih, keď ju potrebujete.

Hlavička nikdy nepresmeruje spojenie

Zápis adresy do poľa preposielania nemení zdroj TCP spojenia prichádzajúceho na server a nemení smerovanie nikde na ceste. Bežné smerovanie VPN alebo zdrojový NAT doručí prevádzku úplne bez akejkoľvek HTTP hlavičky. Rovnako tak tranzitná brána neprepisuje riadne chránenú výmenu HTTPS bez zmeny usporiadania koncového bodu TLS.

Opačná chyba je rovnako častá: HTTPS nerobí hlavičku preposielania poskytnutú klientom pravdivou. Chráni prenos nepravdivého tvrdenia presne tak dobre ako pravdivého.

Ak kolega navrhne zmenu hlavičky na opravu problému so smerovaním, diagnóza už išla zle. Opravte cestu alebo opravte konfiguráciu proxy, ktorá hlavičku zapisuje.

Pomenujte proxy, ktorá smie tvrdiť

Dve pravidlá robia pole preposielania použiteľným a obe sú konfigurácia, nie kód. Okraj normalizuje alebo zahadzuje všetko, čo prichádza zvonka, podľa vlastného dokumentovaného správania pre tieto polia. Potom pôvod berie náhradnú adresu z cesty proxy, ktorú ste pomenovali, a odnikiaľ inak. Druhé pravidlo platí len dovtedy, kým sa klienti nemôžu dostať k pôvodu inak, pretože pôvod, ktorý odpovedá na priame aj cez proxy prichádzajúce požiadavky, nevie, ktorej z nich slúži.

Modul NGINX pre skutočnú IP jasne ukazuje rozdelenie. set_real_ip_from pomenúva odosielateľov, ktorých tvrdenie sa počíta, a real_ip_header hovorí, ktoré pole ho nesie; prvý vykonáva dôveru, druhý iba hovorí, kam sa pozerať.

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

Smernica na výber hlavičky sama o sebe stále nič nestanovuje o tom, kto hodnotu poslal.

Bezpečnosť prenosu musí pôsobiť po celej ceste medzi komponentmi, ktorým dôverujete. Okraj, ktorý správne normalizuje, stráca túto hodnotu v okamihu, keď nechránený medzikrok nižšie dovolí niekomu inému upraviť tvrdenie na ceste.

Vedome zaobchádzajte s reťazcami s viacerými medzikrokmi

Niekoľko proxy vyžaduje výslovný model reťazca. Neberte najľavejšiu ani najpravejšiu hodnotu oddelenú čiarkami len preto, že to urobil nejaký blogový príspevok; zistite, ktorá z vašich proxy pridáva, ktorá nahrádza a ktorá zachováva prichádzajúce pole. Napríklad NGINX môže prejsť zoznam opačne voči svojej množine dôveryhodných a zastaviť sa na prvej adrese, ktorú nevlastní, a to je pravidlo tohto produktu, nie zákon, ktorý dodržiava každý rámec. Čítajte dokumentáciu vlastnej proxy s rovnakými dvoma otázkami: ktorú hodnotu vyberá a ktorým odosielateľom verí?

Zapíšte reťazec: poradie medzikrokov, ktorý medzikrok nastavuje pole a ktorý medzikrok odstraňuje prichádzajúce kópie. Potom držte túto poznámku vedľa konfigurácie proxy, nielen v tikete. Potom to overte odoslaním požiadavky so sfalšovanou hlavičkou cez schválený validačný proces a potvrdením, že pôvod ju ignoruje.

Keď pridáte medzikrok, znova prejdite tento dokument. Nový nástroj na vyvažovanie záťaže vložený pred dôveryhodnú proxy môže zmeniť, ktorá adresa vyhrá, bez toho, aby niekto upravoval aplikáciu.

Uchovajte obe pozorovania v zázname

Tam, kde je diagnostika povolená, zaznamenávajte protipól spojenia a normalizovanú adresu klienta ako dve samostatné polia a pridávajte len tie metadáta preposielania, ktoré účel skutočne potrebuje. Potom dokážte nasadenie dvoma požiadavkami: jednou cez proxy, ktorá by mala rozumne zaznamenať obe hodnoty, a jedným pokusom priamo na pôvod, ktorý musí byť odmietnutý.

Pamätajte, čo táto dvojica znamená. Hlavička pridáva kontext poskytnutý komponentom, ktorému ste sa rozhodli dôverovať; protipól zostáva jedinou adresou, ktorú váš hostiteľ skutočne videl. Ani jedno nie je dôkazom individuálnej identity a návrh, ktorý ktorékoľvek z nich považuje za dôkaz, sa voči niekomu zmýli.