Administrēšanas apakšdomēns neaptur CSRF: četras pārbaudes pirms palaišanas
Jauns resursdatora nosaukums ir jauna izcelsme, bieži tā pati vietne, tāpēc same-site sīkfaili un vienkāršas formas to šķērso. Pārbaudiet marķierus, vārtus un autorizāciju.
Administrēšanas saskarnes pārvietošana uz admin.example.com ir īsts uzlabojums: tā tur administrēšanas sīkfailus tālu no publiskajām lapām, dod abām lietotnēm atsevišķas kešatmiņas un ļauj stingrāku tīkla politiku vērst uz vienu resursdatora nosaukumu. Bet tā nav CSRF kontrole un nepadara publiskās vietnes kodu drošu atstāt atvērtu pieslēgušās administrators priekšā. Atdalīšana maina to, ko pārlūkprogramma uzskata par robežu, nevis to, ko pārbauda serveris, tāpēc veiciet šīs četras pārbaudes, pirms sakāt, ka darbs ir pabeigts.
Lasiet izcelsmi un vietni kā divus dažādus vārdus
Izcelsme ir shēma, resursdators un ports, tāpēc https://www.example.com un https://admin.example.com ir dažādas izcelsmes. Vietne SameSite nozīmē ir shēma plus reģistrējams domēns, tāpēc šie divi resursdatora nosaukumi parasti ir viena vietne. Šī atšķirība ir visas slazds: SameSite atribūts nepalīdzēs starp māsas apakšdomēniem, jo pārlūkprogramma pieprasījumu nemaz neuzskata par starpvietņu. Novirziet administrēšanas saskarni uz patiešām citu reģistrējamu domēnu, piemēram, admin-example.net, un pieprasījums patiešām kļūst starpvietņu, un tieši tur SameSite=Lax vai Strict sāk darīt darbu, uz kuru var paļauties.
Pārbaudiet to pārlūkprogrammā, nevis spriediet par to. Pārbaudiet to pārlūkprogrammā, nevis spriediet par to.
Ielādējiet publisko vietni, atveriet izstrādātāja rīkus un skatieties, kādus sīkfailus pārlūkprogramma pievieno pieprasījumam uz administrēšanas resursdatoru. Ja sīkfailam nav Domain atribūta, tas ir tikai resursdatoram un paliek uz sava nosaukuma; ja tam ir Domain=example.com, tas ceļo pie katras māsas, un jaunais apakšdomēns jums par šo sīkfailu neko nedeva.
Atdaliet atbildes lasīšanu no pieprasījuma sūtīšanas
Vienas izcelsmes politika ierobežo atbilžu lasīšanu starp izcelsmēm. Tā neaptur pieprasījuma nosūtīšanu un neliedz formai pārnēsāt akreditācijas datus, kas pārlūkprogrammai jau ir. Vienkāršs pieprasījums ar formas satura tipu vai vienkāršu GET tiek piegādāts bez iepriekšējas pārbaudes; pēc tam CORS izlemj, vai izsaucējs skripts drīkst lasīt atbildi. CSRF dzīvo pilnībā sūtīšanas pusē.
Tāpēc serverim vajag skaidru pārbaudi operācijām, kas maina stāvokli. Ar sesiju saistīts sinhronizācijas marķieris vai serverī salīdzināts dubultās iesniegšanas sīkfails aptver šo gadījumu; Origin vai Referer salīdzinājumu ir vērts pievienot kā otros vārtus, bet ne kā vienīgos, jo ne katrs pieprasījums nes galveni un ne katrs starpniekserveris to saglabā. OWASP CSRF novēršanas vadlīnijas uzskata SameSite par vienu slāni starp vairākiem tieši šī iemesla dēļ.
Izlemiet, ko tīkla vārti patiešām pierāda
VPN izeju atļauju saraksts administrēšanas resursdatora priekšā ir laba kontrole un vājš identitātes apgalvojums. Tas pierāda, ka pieprasījums nāca no adreses, ko piešķir VPN, ko var kopīgi izmantot visi šajā izejā, un neko nepasaka par to, kura persona vai ierīce ir aiz tā. Uztveriet to kā ieejas filtru, nevis autentifikāciju.
Turiet to neatkarīgu no pieprasījuma līmeņa pārbaudēm. Ja saraksts ir vienīgais starp uzbrucēju un stāvokli mainošu galapunktu, viena nepareizi konfigurēta maršruta, viens split-tunnel klients vai viens aizņemts portatīvais dators pilnībā noņem kontroli.
Reģistrējiet arī atteikumus ārpus gaidītajiem diapazoniem. To uzplūdums ir visnoderīgākais signāls, ka kāds pēta tikko uzbūvēto robežu, un klusums ir signāls, ka filtrs nemaz netiek sasniegts.
Turiet sīkfailus, pieteikšanos un autorizāciju skaidrus
Sīkfaila tvērums izlemj lielāko daļu rezultāta. Vecākdomēna sīkfails tiek nosūtīts administrēšanas resursdatoram, tāpēc skripta ievietošana publiskajā vietnē var darboties ar administratora sesiju; sīkfails tikai resursdatoram to nevar. Dodiet priekšroku tikai resursdatora formai, pievienojiet Secure atribūtu un izmantojiet prefiksu __Host- tur, kur platforma to atbalsta, jo šis prefikss prasa Secure, Path=/ un bez Domain atribūta. Lasiet atbildes galveni, nevis sīkfailu burku: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, bez Domain atribūta. Pārlūkprogramma izmet __Host- sīkfailu ar Domain, tāpēc sīkfails, kas joprojām redzams uz māsas resursdatoriem, ir pierādījums, ka prefikss nekad netika piemērots.
Pēc tam turiet autorizāciju serverī, katram pieprasījumam, katrā administrēšanas galapunktā, nevis tikai pieteikšanās laikā. Pieprasījums no atļauta tīkla joprojām ir jāautentificē un jāautorizē operācijai, ko tas pieprasa; resursdatora nosaukums nav darbības veicējs. Ja publiskā un administrēšanas lietotne dala pieteikšanās plūsmu vai sesiju krātuvi, pierakstiet šo saistību, jo tas ir īsākais ceļš no publiskās vietnes kļūdas līdz administrēšanas darbībai.
Pārbaudiet robežu vēlreiz pēc atdalīšanas
Palaidiet negatīvos testus, ne tikai laimīgo ceļu: forma starp vietnēm bez marķiera ir jānoraida, marķieris no citas sesijas ir jānoraida, un neviens GET nedrīkst mainīt stāvokli. Pārbaudiet sīkfailu atribūtus izstrādātāja rīkos, apstipriniet, ka Origin pārbaude iedarbojas uz neatbilstošu pieprasījumu, un izmēģiniet administrēšanas resursdatoru ārpus VPN diapazona, lai redzētu filtru darbībā.
Nekas no tā neiznīcina XSS defektu pašā administrēšanas lietotnē. Atsevišķs resursdatora nosaukums ir pārlūkprogrammas puses izolācijas robeža ar reālu vērtību, un tas neaizstāj nedrošas koda izpildes novēršanu vai pieprasījumu aizsardzību servera pusē. Pēc atdalīšanas saraksts ir īsāks, nekā izskatās: atšķirīga izcelsme, sīkfaili tikai resursdatoram, marķieris pie katras izmaiņas, ieejas filtrs, kuram neuzticaties kā identitātei, un katram pieprasījumam izlemta autorizācija.