Soketa kontraŭulo kontraŭ plusendita kaplinio: kiun adreson fidi?

Peto alvenanta al via aplikaĵo portas du specojn de adresaj indikoj: la kontraŭulo, kiu malfermis la retan konekton, kaj HTTP-kampo, kiu asertas la adreson de pli frua kliento. Ili respondas malsamajn demandojn. La soketa kontraŭulo estas observata, dum la kaplinion asertas tiu, kiu ĝin skribis, kaj neniu el ili silenteme anstataŭigu la alian en protokolo aŭ en alirregulo. La komparo sube tenas ilin apartaj kaj poste montras la solan aranĝon, en kiu la kaplinio fariĝas uzebla.

Priskribu la vojon antaŭ ol kompari ion ajn:

Client -> approved reverse proxy -> application origin

En tiu aranĝo la soketa kontraŭulo de la origino estas kutime la prokuro, kaj plusenda kaplinio povas porti la aserton de la prokuro pri la kliento. Ĝia valoro venas el la kontrolita rilato kun tiu prokuro, ne el la nomo de la kaplinio.

Du specoj de adresaj indikoj

La soketa kontraŭulo estas fakto pri unu TCP-konekto: io kompletigis manpremon el tiu adreso. Ĝi ne nepre estas la homo, la aparato aŭ la konto, pri kiu vi zorgas, ĉar VPN aŭ Tor-eliro povas laŭleĝe esti la fonto, kiun servo observas. Ĝi tamen restas la sola adreso, kiun la gastiganto mem kontrolis, kaj en tio estas ĝia tuta valoro.

Plusenda kampo estas metadatumoj pri ĉeno. X-Forwarded-For, X-Real-IP kaj la normigita kampo Forwarded povas esti skribita de iu ajn kliento, kiu atingas finpunkton, kiu redonas ilin, do ilia fidindeco tute dependas de tio, al kiu estis permesite agordi ilin.

Tenu ambaŭ en la peta kunteksto sub apartaj nomoj. Aplikaĵo, kiu anstataŭigas la kontraŭulon per la kaplinio, perdas la kapablon poste rekonstrui fid-eraron, kaj tio estas ĝuste la momento, kiam vi bezonas ĝin.

Kaplinio neniam alidirektas la konekton

Skribi adreson en plusendan kampon ne ŝanĝas la fonton de la TCP-konekto alvenanta ĉe la servilo, kaj ĝi ne ŝanĝas la enkursigon ie ajn laŭ la vojo. Ordinara VPN-enkursigo aŭ fonta NAT liveras trafikon tute sen ajna HTTP-kaplinio. Same, traira enirejo ne reskribas ĝuste protektitan HTTPS-interŝanĝon sen ŝanĝi la aranĝon de la TLS-fimpunkto.

La kontraŭa eraro estas same ofta: HTTPS ne igas plusendan kaplinion havigitan de la kliento vera. Ĝi protektas la transporton de falsa aserto same bone kiel de vera.

Se kolego proponas kaplinian ŝanĝon por ripari enkursigan problemon, la diagnozo jam iris malbone. Riparu la vojon, aŭ riparu la prokuran agordon, kiu skribas la kaplinion.

Nomu la prokuron permesitan aserti

Du reguloj igas plusendan kampon uzebla, kaj ambaŭ estas agordo, ne kodo. La rando normaligas aŭ forĵetas ĉion, kio alvenas de ekstere, laŭ sia propra dokumentita konduto por tiuj kampoj. Poste la origino prenas anstataŭan adreson el la prokura vojo, kiun vi nomis, kaj el nenio alia. Tiu dua regulo validas nur dum klientoj ne povas atingi la originon alimaniere, ĉar origino, kiu respondas al kaj rektaj kaj prokuraj petoj, havas neniun ideon, kiun el ili ĝi servas.

NGINX-modulo por la reala IP montras la disigon klare. set_real_ip_from nomas la sendantojn, kies aserto gravas, kaj real_ip_header diras, kiu kampo portas ĝin; la unua faras la fidon, la dua nur diras, kie rigardi.

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

Kaplinia elekta direktivo sola ankoraŭ establas nenion pri tio, kiu sendis la valoron.

Transporta sekureco devas iri la tutan vojon inter la komponantoj, kiujn vi fidas. Rando, kiu ĝuste normaligas, perdas tiun valoron en la momento, kiam neprotektita salto malsupre lasas iun alian redakti la aserton dum ĝi vojaĝas.

Traktu multsaltajn ĉenojn konscie

Pluraj prokuroj bezonas klaran ĉenan modelon. Ne prenu la plej maldekstran aŭ plej dekstran komoapartigitan valoron ĉar iu blogaĵo tion faris; eltrovu, kiu el viaj prokuroj aldonas, kiu anstataŭigas kaj kiu konservas la envenantan kampon. NGINX, ekzemple, povas trairi la liston malantaŭen kontraŭ sia fidata aro kaj halti ĉe la unua adreso, kiun ĝi ne posedas, kaj tio estas regulo de tiu produkto, ne leĝo, kiun sekvas ĉiu kadro. Legu la dokumentaron de via propra prokuro kun la samaj du demandoj: kiun valoron ĝi elektas, kaj kiujn sendantojn ĝi kredas?

Skribu la ĉenon: salta ordo, kiu salto agordas la kampon, kaj kiu salto forigas envenantajn kopiojn. Poste tenu tiun noton apud la prokura agordo, ne nur en la bileto. Poste testu ĝin sendante peton kun falsigita kaplinio tra la aprobita validiga procezo kaj konfirmante, ke la origino ignoras ĝin.

Kiam vi aldonas salton, revizitu tiun dokumenton. Nova ŝarĝbalancilo enmetita antaŭ la fidata prokuro povas ŝanĝi, kiu adreso venkas, sen ke iu redaktu la aplikaĵon.

Tenu ambaŭ observojn en la protokolo

Kie diagnozado estas rajtigita, protokolu la konektan kontraŭulon kaj la normaligitan klientan adreson kiel du apartajn kampojn, kaj aldonu nur la plusendajn metadatumojn, kiujn la celo efektive bezonas. Poste pruvu la deplojon per du petoj: unu prokura, kiu devus prudente registri ambaŭ valorojn, kaj unu provo rekte al la origino, kiu devas esti rifuzita.

Memoru, kion la paro signifas. La kaplinio aldonas kuntekston havigitan de komponanto, kiun vi elektis fidi; la kontraŭulo restas la sola adreso, kiun via gastiganto efektive vidis. Neniuj el ili estas pruvo de individua identeco, kaj dezajno, kiu traktas iun ajn el ili kiel pruvon, eraros pri iu.