Mwenza wa soketi au kichwa kilichosambazwa: anwani ipi uamini?

Ombi linalofika kwenye programu yako hubeba aina mbili za ushahidi wa anwani: mwenza aliyefungua muunganisho wa mtandao, na sehemu ya HTTP inayodai anwani ya mteja wa awali. Zinajibu maswali tofauti. Mwenza wa soketi huzingatiwa, ilhali kichwa kinadaiwa na yeyote aliyekiandika, na hakuna kimoja kinachopaswa kuchukua nafasi ya kingine kwa ukimya katika kumbukumbu au kanuni ya ufikiaji. Ulinganisho ulio hapa chini unawatenganisha, kisha unaonyesha mpangilio mmoja tu ambao kichwa kinakuwa na matumizi.

Eleza njia kabla ya kulinganisha kitu chochote:

Client -> approved reverse proxy -> application origin

Katika mpangilio huo, mwenza wa soketi wa chanzo kwa kawaida ni proksi, na kichwa cha uwasilishaji kinaweza kubeba madai ya proksi kuhusu mteja. Thamani yake inatoka kwenye uhusiano unaodhibitiwa na proksi huyo, si kwenye jina la kichwa.

Aina mbili za ushahidi wa anwani

Mwenza wa soketi ni ukweli kuhusu muunganisho mmoja wa TCP: kitu fulani kilikamilisha kupeana mkono kutoka anwani hiyo. Si lazima awe mtu, kifaa au akaunti unayojali, kwa sababu VPN au njia ya kutokea ya Tor inaweza kuwa chanzo halali ambacho huduma huzingatia. Hata hivyo inabaki kuwa anwani pekee ambayo mwenyeji mwenyewe alithibitisha, na hapo ndipo thamani yake yote ilipo.

Sehemu ya uwasilishaji ni metadata kuhusu mnyororo. X-Forwarded-For, X-Real-IP na sehemu iliyosafishwa Forwarded inaweza kuandikwa na mteja yeyote anayefikia kituo cha mwisho kinachozirudisha, kwa hivyo uaminifu wao unategemea kabisa ni nani aliyeruhusiwa kuziweka.

Weka zote mbili katika muktadha wa ombi chini ya majina tofauti. Programu inayobadilisha mwenza kwa kichwa hupoteza uwezo wa kujenga upya hitilafu ya uaminifu baadaye, na huo ndio wakati hasa unaouhitaji.

Kichwa hakiwahi kubadilisha njia ya muunganisho

Kuandika anwani kwenye sehemu ya uwasilishaji hakubadilishi chanzo cha muunganisho wa TCP unaofika kwenye seva, na hakubadilishi uelekezaji mahali popote kwenye njia. Uelekezaji wa kawaida wa VPN au NAT ya chanzo huleta trafiki bila kichwa chochote cha HTTP. Vivyo hivyo, lango la upitishaji haliandiki upya mabadilishano ya HTTPS yaliyolindwa ipasavyo bila kubadilisha mpangilio wa kituo cha mwisho cha TLS.

Hitilafu iliyo kinyume ni ya kawaida vile vile: HTTPS haifanyi kichwa cha uwasilishaji kilichotolewa na mteja kuwa kweli. Inalinda usafirishaji wa madai ya uongo kama vile ya kweli.

Iwapo mwenzako apendekeza mabadiliko ya kichwa ili kurekebisha tatizo la uelekezaji, utambuzi umeenda kombo tayari. Rekebisha njia, au rekebisha usanidi wa proksi unaoandika kichwa.

Taja proksi inayoruhusiwa kudai

Kanuni mbili hufanya sehemu ya uwasilishaji iwe na matumizi, na zote mbili ni usanidi si msimbo. Ukingo husawazisha au hutupa kila kitu kinachotoka nje, kwa kufuata tabia yake iliyoandikwa kwa sehemu hizo. Kisha chanzo huchukua anwani mbadala kutoka kwenye njia ya proksi uliyoitaja na si mahali pengine popote. Kanuni ya pili inashikilia tu wakati wateja hawawezi kufikia chanzo kwa njia nyingine, kwa sababu chanzo kinachojibu maombi ya moja kwa moja na yale ya proksi hakijui kinamtumikia yupi kati yao.

Moduli ya IP halisi ya NGINX inaonyesha mgawanyiko huo kwa uwazi. set_real_ip_from hutaja watumaji ambao madai yao yanahesabiwa, na real_ip_header husema sehemu ipi inaibeba; ya kwanza hufanya uaminifu, ya pili husema tu wapi pa kuangalia.

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

Maelekezo ya kuchagua kichwa peke yake bado hayathibitishi chochote kuhusu ni nani aliyetuma thamani hiyo.

Usalama wa usafirishaji lazima upite njia yote kati ya vipengele unavyoviamini. Ukingo unaosawazisha ipasavyo hupoteza thamani hiyo wakati hatua isiyolindwa chini inapomruhusu mtu mwingine kuhariri dai wakati linasafiri.

Shughulikia minyororo ya hatua nyingi kwa makusudi

Proksi kadhaa zinahitaji modeli ya mnyororo iliyo wazi. Usichukue thamani ya kushoto au kulia iliyotenganishwa kwa koma kwa sababu chapisho fulani la blogu lilifanya hivyo; gundua ni proksi ipi yako inayoongeza, ipi inayobadilisha na ipi inayohifadhi sehemu inayoingia. Kwa mfano, NGINX inaweza kupita orodha kinyume chake dhidi ya seti yake ya kuaminika na kusimama kwenye anwani ya kwanza ambayo haina umiliki nayo, na hiyo ni kanuni ya bidhaa hiyo, si sheria ambayo kila mfumo hufuata. Soma nyaraka za proksi yako mwenyewe kwa maswali yale yale mawili: inachagua thamani ipi, na inawaamini watumaji gani?

Andika mnyororo: mpangilio wa hatua, hatua ipi inaweka sehemu na hatua ipi inaondoa nakala zinazoingia. Kisha weka noti hiyo kando ya usanidi wa proksi, si kwenye tiketi pekee. Kisha ijaribu kwa kutuma ombi lenye kichwa cha kughushi kupitia mchakato ulioidhinishwa wa uthibitishaji na kuthibitisha kuwa chanzo kinaipuuza.

Unapoongeza hatua, pitia hati hiyo upya. Kisisitizaji kipya cha mzigo kilichowekwa mbele ya proksi inayoaminika kinaweza kubadilisha anwani ipi inashinda bila mtu yeyote kuhariri programu.

Weka uchunguzi wote wawili kwenye kumbukumbu

Mahali ambapo utambuzi unaruhusiwa, rekodi mwenza wa muunganisho na anwani ya mteja iliyosawazishwa kama sehemu mbili tofauti, na ongeza metadata ya uwasilishaji ambayo lengo linahitaji kweli. Kisha thibitisha usambazaji kwa maombi mawili: moja kupitia proksi ambayo inapaswa kurekodi thamani zote mbili kwa busara, na jaribio moja la moja kwa moja kwa chanzo ambalo lazima likataliwe.

Kumbuka maana ya jozi hiyo. Kichwa huongeza muktadha unaotolewa na kipengele ulichochagua kukiamini; mwenza hubaki kuwa anwani pekee ambayo mwenyeji wako aliona kweli. Hakuna hata kimoja kilicho ushahidi wa utambulisho wa mtu binafsi, na muundo unaochukua kimoja wapo kama ushahidi utakosea kuhusu mtu fulani.