Kikoa kidogo cha usimamizi hakizuii CSRF: ukaguzi nne kabla ya kuzindua

Kuhamisha kiolesura cha usimamizi hadi admin.example.com ni uboreshaji wa kweli: huweka vidakuzi vya usimamizi mbali na kurasa za umma, huwapa programu mbili akiba tofauti na hukuwezesha kuelekeza sera kali ya mtandao kwenye jina moja la mwenyeji. Lakini si udhibiti wa CSRF, na haifanyi msimbo wa tovuti ya umma kuwa salama kuachwa wazi mbele ya msimamizi aliyeingia. Utenganishaji hubadilisha kile kivinjari kinachukulia kama mpaka, si kile seva inakagua, kwa hivyo fanya ukaguzi huu nne kabla ya kusema imekamilika.

Soma asili na tovuti kama maneno mawili tofauti

Asili ni mpango, mwenyeji na bandari, kwa hivyo https://www.example.com na https://admin.example.com ni asili tofauti. Tovuti kwa maana ya SameSite ni mpango pamoja na kikoa kinachoweza kusajiliwa, kwa hivyo majina hayo mawili ya mwenyeji kwa kawaida ni tovuti moja. Tofauti hiyo ndiyo mtego wote: sifa ya SameSite haitakusaidia kati ya vikoa vidogo ndugu, kwa sababu kivinjari hakichukulii ombi hilo kama la kuvuka tovuti kabisa. Elekeza kiolesura cha usimamizi kwenye kikoa kingine halisi kinachoweza kusajiliwa, kama admin-example.net, na ombi linakuwa la kuvuka tovuti kweli, na hapo ndipo SameSite=Lax au Strict huanza kufanya kazi unayoweza kuitegemea.

Ijaribu kwenye kivinjari badala ya kufikiri juu yake.

Pakia tovuti ya umma, fungua zana za msanidi na uone ni vidakuzi gani kivinjari kinaambatanisha na ombi linaloelekea mwenyeji wa usimamizi. Ikiwa kidakuzi hakina sifa ya Domain, ni cha mwenyeji tu na hubaki kwenye jina lake; ikiwa kina Domain=example.com, huenda kwa kila ndugu, na kikoa kipya hakikukupa chochote kwa kidakuzi hicho.

Tenganisha kusoma jibu na kutuma ombi

Sera ya asili moja huzuia kusoma majibu kati ya asili. Haizuii ombi kutumwa, na haizuii fomu kubeba vitambulisho ambavyo kivinjari tayari kinavyo. Ombi rahisi, lenye aina ya maudhui ya fomu au GET ya kawaida, huwasilishwa bila ukaguzi wa awali; kisha CORS huamua ikiwa hati inayopiga simu inaweza kusoma jibu. CSRF huishi kabisa upande wa kutuma.

Ndiyo sababu seva inahitaji ukaguzi wazi kwa shughuli zinazobadilisha hali. Tokeni ya usawazishaji iliyofungwa na kipindi, au kidakuzi cha kutuma mara mbili kinacholinganishwa kwenye seva, hufunika hali hiyo; kulinganisha Origin au Referer kunafaa kuongezwa kama lango la pili lakini si la pekee, kwa sababu si kila ombi hubeba kichwa hicho na si kila proksi hukihifadhi. Mwongozo wa OWASP wa kuzuia CSRF huchukulia SameSite kama tabaka moja kati ya kadhaa, kwa sababu hii hasa.

Amua kile lango la mtandao linathibitisha kweli

Orodha ya kuruhusiwa ya njia za kutoka za VPN mbele ya mwenyeji wa usimamizi ni udhibiti mzuri na dai dhaifu la utambulisho. Inathibitisha kwamba ombi lilitoka kwenye anwani ambayo VPN hutoa, ambayo wote waliopo kwenye njia hiyo wanaweza kushiriki, na haisemi chochote kuhusu mtu au kifaa kilicho nyuma yake. Ichukulie kama chujio cha kuingia, si kama uthibitishaji.

Iweke huru kutoka kwa ukaguzi wa ngazi ya ombi. Ikiwa orodha ni kitu pekee kati ya mshambuliaji na sehemu ya mwisho inayobadilisha hali, njia moja iliyowekwa vibaya, mteja mmoja wa split-tunnel au kompyuta mpakato iliyoazimwa huondoa udhibiti kabisa.

Rekodi pia kukataliwa kutoka nje ya safu zinazotarajiwa. Mlipuko wao ni ishara yenye manufaa zaidi kwamba mtu anachunguza mpaka ulioujenga hivi punde, na ukimya ni ishara kwamba chujio hakifikiki kabisa.

Tunza vidakuzi, kuingia na idhini wazi

Upeo wa kidakuzi huamua sehemu kubwa ya matokeo. Kidakuzi cha kikoa cha mzazi hutumwa kwa mwenyeji wa usimamizi, kwa hivyo uingizaji wa hati kwenye tovuti ya umma unaweza kufanya kazi na kipindi cha msimamizi; kidakuzi cha mwenyeji pekee hakiwezi. Pendelea umbo la mwenyeji pekee, ongeza sifa ya Secure na tumia kiambishi awali __Host- pale jukwaa linaposaidia, kwa sababu kiambishi hicho kinahitaji Secure, Path=/ na hakuna sifa ya Domain. Soma kichwa cha jibu na si chupa ya vidakuzi: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, bila sifa ya Domain. Kivinjari hutupa kidakuzi cha __Host- kilicho na Domain, kwa hivyo kidakuzi kinachoonekana bado kwenye wenyeji ndugu ni uthibitisho kwamba kiambishi hakikutumika kamwe.

Kisha weka idhini kwenye seva, kwa kila ombi, kwenye kila sehemu ya mwisho ya usimamizi, si tu wakati wa kuingia. Ombi kutoka mtandao ulioruhusiwa bado linapaswa kuthibitishwa na kupewa idhini kwa shughuli inayoiomba; jina la mwenyeji si mhusika. Ikiwa programu za umma na usimamizi zinashiriki mtiririko wa kuingia au hifadhi ya vipindi, andika uhusiano huo, kwa sababu ndiyo njia fupi zaidi kutoka hitilafu kwenye tovuti ya umma hadi hatua ya usimamizi.

Kagua mpaka tena baada ya utenganishaji

Endesha majaribio hasi, si njia ya furaha pekee: fomu ya kuvuka tovuti bila tokeni lazima ikataliwe, tokeni kutoka kipindi kingine lazima ikataliwe, na hakuna GET inayopaswa kubadilisha hali. Kagua sifa za vidakuzi kwenye zana za msanidi, thibitisha kwamba ukaguzi wa Origin huwaka kwenye ombi lisilolingana, na jaribu mwenyeji wa usimamizi kutoka nje ya safu ya VPN ili kuona chujio kikifanya kazi.

Hakuna hata moja ya haya inaondoa kasoro ya XSS ndani ya programu ya usimamizi yenyewe. Jina tofauti la mwenyeji ni mpaka wa kutenganisha upande wa kivinjari wenye thamani halisi, na si mbadala wa kuzuia utekelezaji wa msimbo usio salama au wa kulinda maombi upande wa seva. Baada ya utenganishaji orodha ni fupi kuliko inavyoonekana: asili tofauti, vidakuzi vya mwenyeji pekee, tokeni kwa kila mabadiliko, chujio cha kuingia usichokiamini kama utambulisho, na idhini inayoamuliwa kwa kila ombi.