Subdomain admin tidak menghentikan CSRF: empat pemeriksaan sebelum pelancaran

Memindahkan antara muka pentadbiran ke admin.example.com ialah penambahbaikan sebenar: ia menjauhkan kuki pentadbiran daripada halaman awam, memberikan kedua-dua aplikasi cache berasingan dan membolehkan anda mengarahkan dasar rangkaian yang lebih ketat kepada satu nama hos. Tetapi ia bukan kawalan CSRF, dan ia tidak menjadikan kod laman awam selamat untuk dibiarkan terbuka di hadapan pentadbir yang telah log masuk. Pemisahan mengubah apa yang dianggap sempadan oleh pelayar, bukan apa yang diperiksa oleh pelayan, jadi lakukan empat pemeriksaan ini sebelum mengatakan ia selesai.

Baca asal dan laman sebagai dua perkataan berbeza

Asal ialah skema, hos dan port, jadi https://www.example.com dan https://admin.example.com ialah asal yang berbeza. Laman, dalam erti SameSite, ialah skema tambah domain yang boleh didaftarkan, jadi kedua-dua nama hos itu biasanya laman yang sama. Perbezaan itulah keseluruhan perangkap: atribut SameSite tidak akan membantu anda antara subdomain bersaudara, kerana pelayar langsung tidak menganggap permintaan itu merentas laman. Halakan antara muka pentadbiran kepada domain berdaftar yang benar-benar berbeza, seperti admin-example.net, dan permintaan itu benar-benar menjadi merentas laman, dan di situlah SameSite=Lax atau Strict mula melakukan kerja yang boleh anda harapkan.

Ujinya dalam pelayar dan bukan menaakul tentangnya.

Muatkan laman awam, buka alat pembangun dan lihat kuki mana yang dilampirkan pelayar pada permintaan ke hos pentadbiran. Jika kuki tiada atribut Domain, ia hanya untuk hos dan kekal pada namanya sendiri; jika ia membawa Domain=example.com, ia bergerak ke setiap saudara, dan subdomain baharu tidak memberikan apa-apa kepada anda untuk kuki itu.

Pisahkan keupayaan membaca respons daripada menghantar permintaan

Dasar asal yang sama mengehadkan pembacaan respons antara asal. Ia tidak menghentikan permintaan dihantar, dan ia tidak menghalang borang membawa kelayakan yang sudah dimiliki pelayar. Permintaan ringkas, dengan jenis kandungan borang atau GET biasa, dihantar tanpa pemeriksaan awal; CORS kemudian memutuskan sama ada skrip yang memanggil boleh membaca jawapannya. CSRF hidup sepenuhnya di sebelah penghantaran.

Itulah sebabnya pelayan memerlukan pemeriksaan jelas untuk operasi yang mengubah keadaan. Token penyegerakan yang terikat pada sesi, atau kuki hantaran berganda yang dibandingkan di pelayan, meliputi kes itu; perbandingan Origin atau Referer wajar ditambah sebagai pintu kedua tetapi bukan satu-satunya, kerana bukan setiap permintaan membawa pengepala itu dan bukan setiap proksi menyimpannya. Panduan OWASP untuk mencegah CSRF menganggap SameSite sebagai satu lapisan antara beberapa, tepat atas sebab ini.

Putuskan apa yang sebenarnya dibuktikan oleh pintu rangkaian

Senarai benaran keluar VPN di hadapan hos pentadbiran ialah kawalan yang baik dan dakwaan identiti yang lemah. Ia membuktikan bahawa permintaan datang dari alamat yang diberikan VPN, yang boleh dikongsi oleh semua orang di keluar itu, dan ia tidak mengatakan apa-apa tentang siapa orang atau peranti di belakangnya. Layaninya sebagai penapis masuk, bukan sebagai pengesahan identiti.

Kekalkannya bebas daripada pemeriksaan peringkat permintaan. Jika senarai itu satu-satunya perkara antara penyerang dan titik akhir yang mengubah keadaan, satu laluan yang salah dikonfigurasikan, satu klien split-tunnel atau satu komputer riba yang dipinjam menghapuskan kawalan itu sepenuhnya.

Catat juga penolakan dari luar julat yang dijangka. Lonjakannya ialah isyarat paling berguna bahawa seseorang sedang menyiasat sempadan yang baru anda bina, dan kesunyian ialah isyarat bahawa penapis langsung tidak dicapai.

Kekalkan kuki, log masuk dan kebenaran secara jelas

Skop kuki menentukan sebahagian besar hasil. Kuki domain induk dihantar ke hos pentadbiran, jadi suntikan skrip di laman awam boleh bertindak dengan sesi pentadbir; kuki khusus hos tidak boleh. Utamakan bentuk khusus hos, tambah atribut Secure dan gunakan awalan __Host- di tempat platform menyokongnya, kerana awalan itu memerlukan Secure, Path=/ dan tiada atribut Domain. Baca pengepala respons dan bukan balang kuki: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, tanpa atribut Domain. Pelayar membuang kuki __Host- yang membawa Domain, jadi kuki yang masih kelihatan pada hos bersaudara ialah bukti bahawa awalan itu tidak pernah digunakan.

Selepas itu kekalkan kebenaran di pelayan, bagi setiap permintaan, pada setiap titik akhir pentadbiran, bukan hanya semasa log masuk. Permintaan dari rangkaian yang dibenarkan masih perlu disahkan identiti dan dibenarkan untuk operasi yang dimintanya; nama hos bukan pelaku. Jika aplikasi awam dan pentadbiran berkongsi aliran log masuk atau storan sesi, tuliskan hubungan itu, kerana itulah laluan terpendek dari pepijat laman awam ke tindakan pentadbiran.

Periksa semula sempadan selepas pemisahan

Jalankan ujian negatif, bukan hanya laluan gembira: borang merentas laman tanpa token mesti ditolak, token dari sesi lain mesti ditolak, dan tiada GET boleh mengubah keadaan. Periksa atribut kuki dalam alat pembangun, sahkan pemeriksaan Origin tercetus pada permintaan yang tidak sepadan, dan cuba hos pentadbiran dari luar julat VPN untuk melihat penapis berfungsi.

Tiada satu pun daripada ini menghapuskan kecacatan XSS di dalam aplikasi pentadbiran itu sendiri. Nama hos berasingan ialah sempadan pengasingan sebelah pelayar yang mempunyai nilai sebenar, dan ia bukan pengganti pencegahan pelaksanaan kod tidak selamat atau perlindungan permintaan di sebelah pelayan. Selepas pemisahan senarainya lebih pendek daripada yang kelihatan: asal berbeza, kuki khusus hos, token pada setiap perubahan, penapis masuk yang anda tidak percaya sebagai identiti, dan kebenaran yang diputuskan bagi setiap permintaan.