Subdomain admin tidak menghentikan CSRF: empat pemeriksaan sebelum peluncuran

Memindahkan antarmuka administratif ke admin.example.com adalah perbaikan nyata: ia menjauhkan cookie admin dari halaman publik, memberi kedua aplikasi cache terpisah, dan memungkinkan Anda mengarahkan kebijakan jaringan yang lebih ketat ke satu nama host. Tetapi itu bukan kontrol CSRF, dan tidak membuat kode situs publik aman untuk dibiarkan terbuka di depan administrator yang sudah masuk. Pemisahan mengubah apa yang dianggap batas oleh peramban, bukan apa yang diperiksa server, jadi lakukan empat pemeriksaan ini sebelum menyebutnya selesai.

Bacalah origin dan situs sebagai dua kata berbeda

Origin adalah skema, host, dan port, jadi https://www.example.com dan https://admin.example.com adalah origin berbeda. Situs, dalam arti SameSite, adalah skema plus domain yang dapat didaftarkan, jadi kedua nama host itu biasanya situs yang sama. Perbedaan itulah seluruh jebakannya: atribut SameSite tidak akan membantu Anda di antara subdomain saudara, karena peramban sama sekali tidak menganggap permintaan itu lintas situs. Arahkan antarmuka admin ke domain terdaftar yang benar-benar berbeda, seperti admin-example.net, dan permintaan itu benar-benar menjadi lintas situs, dan di situlah SameSite=Lax atau Strict mulai melakukan pekerjaan yang bisa Anda andalkan.

Ujilah di peramban alih-alih menalar tentangnya.

Muat situs publik, buka alat pengembang, dan lihat cookie mana yang dilampirkan peramban pada permintaan ke host admin. Jika cookie tidak memiliki atribut Domain, ia hanya untuk host dan tetap di nama hostnya sendiri; jika membawa Domain=example.com, ia pergi ke setiap saudara, dan subdomain baru tidak memberi Anda apa pun untuk cookie itu.

Pisahkan kemampuan membaca respons dari kemampuan mengirim permintaan

Kebijakan asal yang sama membatasi pembacaan respons antar origin. Kebijakan itu tidak menghentikan permintaan dikirim, dan tidak mencegah formulir membawa kredensial yang sudah dimiliki peramban. Permintaan sederhana, dengan tipe konten formulir atau GET biasa, dikirim tanpa pemeriksaan awal; CORS kemudian memutuskan apakah skrip pemanggil boleh membaca jawabannya. CSRF hidup sepenuhnya di sisi pengiriman.

Karena itu server memerlukan pemeriksaan eksplisit untuk operasi yang mengubah status. Token sinkronisasi yang terikat sesi, atau cookie pengiriman ganda yang dibandingkan di server, menutup kasus itu; perbandingan Origin atau Referer layak ditambahkan sebagai gerbang kedua tetapi bukan satu-satunya, karena tidak setiap permintaan membawa header itu dan tidak setiap proksi menyimpannya. Panduan OWASP untuk mencegah CSRF memperlakukan SameSite sebagai satu lapisan di antara beberapa justru karena alasan ini.

Putuskan apa yang sebenarnya dibuktikan gerbang jaringan

Daftar izin keluar VPN di depan host admin adalah kontrol yang baik dan klaim identitas yang lemah. Ia membuktikan bahwa permintaan datang dari alamat yang diberikan VPN, yang dapat dipakai bersama oleh semua orang di keluar itu, dan tidak mengatakan apa pun tentang siapa orang atau perangkat di belakangnya. Perlakukan sebagai penyaring masuk, bukan sebagai autentikasi.

Jaga agar tetap independen dari pemeriksaan tingkat permintaan. Jika daftar itu satu-satunya hal antara penyerang dan titik akhir yang mengubah status, satu rute salah konfigurasi, satu klien split-tunnel, atau satu laptop pinjaman menghapus kontrol itu sepenuhnya.

Catat juga penolakan dari luar rentang yang diharapkan. Lonjakannya adalah sinyal paling berguna bahwa seseorang sedang menyelidiki batas yang baru Anda bangun, dan kesunyian adalah sinyal bahwa penyaring tidak dijangkau sama sekali.

Jaga cookie, proses masuk, dan otorisasi tetap eksplisit

Cakupan cookie menentukan sebagian besar hasil. Cookie domain induk dikirim ke host admin, jadi injeksi skrip di situs publik dapat bertindak dengan sesi administrator; cookie khusus host tidak bisa. Utamakan bentuk khusus host, tambahkan atribut Secure, dan gunakan awalan __Host- di tempat platform mendukungnya, karena awalan itu mensyaratkan Secure, Path=/ dan tanpa atribut Domain. Baca header respons, bukan toples cookie: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, tanpa atribut Domain. Peramban membuang cookie __Host- yang membawa Domain, jadi cookie yang masih terlihat di host saudara adalah bukti bahwa awalan itu tidak pernah diterapkan.

Lalu jagalah otorisasi di server, per permintaan, di setiap titik akhir administratif, bukan hanya saat masuk. Permintaan dari jaringan yang diizinkan tetap harus diautentikasi dan diotorisasi untuk operasi yang dimintanya; nama host bukan pelaku. Jika aplikasi publik dan admin berbagi alur masuk atau penyimpanan sesi, tuliskan hubungan itu, karena itulah jalur terpendek dari bug situs publik ke tindakan administratif.

Periksa ulang batas setelah pemisahan

Jalankan pengujian negatif, bukan hanya jalur bahagia: formulir lintas situs tanpa token harus ditolak, token dari sesi lain harus ditolak, dan tidak ada GET yang boleh mengubah status. Periksa atribut cookie di alat pengembang, pastikan pemeriksaan Origin menyala pada permintaan yang tidak cocok, dan coba host admin dari luar rentang VPN untuk melihat penyaring bekerja.

Tidak satu pun dari ini menghapus cacat XSS di dalam aplikasi admin itu sendiri. Nama host terpisah adalah batas isolasi sisi peramban dengan nilai nyata, dan itu bukan pengganti pencegahan eksekusi kode tidak aman atau perlindungan permintaan di sisi server. Setelah pemisahan daftarnya lebih pendek daripada kelihatannya: origin berbeda, cookie khusus host, token pada setiap mutasi, penyaring masuk yang tidak Anda percayai sebagai identitas, dan otorisasi yang diputuskan per permintaan.