Checklist Review CSRF dan Cookie SameSite
CSRF memanfaatkan credential yang otomatis dikirim browser pada request lintas situs. SameSite mengurangi sebagian kasus, tetapi bukan pemeriksaan otorisasi dan dapat merusak alur federasi yang sah.
Identifikasi route yang mengubah state
Daftarkan semua route POST, PUT, PATCH, dan DELETE yang memakai autentikasi cookie. Contoh: perubahan rekening tujuan wajib memakai token yang diverifikasi server. Contoh lain: route logout mungkin berdampak kecil, tetapi tetap tidak boleh membuat state lintas situs membingungkan.
Tabel keputusan kontrol
| Alur | Kontrol utama | Pemeriksaan browser |
|---|---|---|
| form same-site | synchronizer token | token kosong ditolak |
| API JSON | custom header dan CORS | situs lain tidak dapat mengatur header |
| callback pihak ketiga | origin dan state yang tepat | return yang dimaksud berfungsi |
| cookie | pilihan SameSite eksplisit | perilaku cookie diamati |
Panduan CSRF OWASP, referensi Set-Cookie, dan CWE-352 adalah rujukan langsung.
Aturan keputusan: setiap perubahan state dengan autentikasi cookie memerlukan verifikasi server yang terikat origin.
Remediasi
Gunakan token per sesi atau per request bila sesuai, verifikasi Origin pada route sensitif, dan uji alur embedded atau SSO sebelum memperketat SameSite. Keberadaan token saja tidak melindungi dari XSS. Pengujian web dapat menjalankan uji di browser nyata.
Verifikasi niat sebelum perubahan state
Daftarkan setiap method tidak aman yang memakai autentikasi cookie beserta alur browser yang diharapkan. Gunakan pertahanan CSRF framework bila tersedia. Jika tidak, terbitkan synchronizer token server yang tidak dapat ditebak atau signed double-submit token yang terikat sesi, wajibkan pengiriman eksplisit di luar cookie, dan verifikasi sebelum mutasi state. Periksa Origin atau Fetch Metadata sebagai defense in depth dengan fallback terdokumentasi. Setting SameSite, Secure, dan HttpOnly melindungi properti berbeda dan harus dipilih per alur.
Jalankan upaya form lintas situs, request tanpa token, token sesi salah, kasus CORS preflight, serta return SSO atau embedded. Catat apakah state berubah, bukan hanya status code. Owner: pemilik identitas. Lulus: request palsu gagal tanpa perubahan state sementara alur sah berfungsi. Gagal: credential browser mengotorisasi request tanpa verifikasi atau hardening merusak alur wajib. Pengecualian menyebut route, perilaku lintas situs yang diperlukan, verifikasi alternatif, approver, remediasi, dan kedaluwarsa.
Catatan keputusan cookie
Nyatakan alasan tiap cookie autentikasi memerlukan Lax, Strict, atau None plus Secure; default browser bukan kebijakan terdokumentasi. Return SSO lintas situs dapat memerlukan pengecualian sempit, tetapi tetap perlu validasi state yang terikat sesi pemulai. Simpan versi browser dan capture cookie karena perilaku pengiriman dimediasi browser.
Catatan otorisasi mutasi
Output yang diharapkan: route, method HTTP, mode sesi, ID penerbitan token, hasil token, nilai Origin atau Fetch Metadata, atribut cookie, hasil side effect. Bukti ini menghubungkan verifikasi request dengan mutasi yang tercatat.
Kegagalan teruji: Form lintas situs mengirim cookie sesi valid tetapi tanpa token. Server harus menolak sebelum menulis transfer atau perubahan preferensi.
Kasus tepi: Callback SSO dapat memerlukan SameSite=None dengan Secure. Validasi state terhadap sesi pemulai dan batasi pengecualian pada route callback.
Uji penutupan: Ulangi request lintas situs pada browser target yang didukung. Penutupan lulus bila state tidak berubah dan alur same-site yang dimaksud tetap berfungsi.
Drill asal request
Petakan endpoint mutasi berdasarkan mekanisme autentikasi. Sesi cookie memerlukan penanganan CSRF; API bearer-token mungkin memerlukan kontrol lintas origin berbeda tetapi tetap membutuhkan otorisasi. Untuk tiap route cookie, dokumentasikan lokasi token, urutan validasi, kebijakan Origin, dan perilaku ketika header tidak ada. Proxy dapat mengubah host atau scheme yang dipersepsikan, sehingga batas trusted proxy harus dikonfigurasi eksplisit dan target origin perlu diuji terhadap nilai deployment.
Gunakan otomasi browser atau kasus manual terkontrol untuk mengirim form bermusuhan dari origin lain. Periksa database dan output audit setelah respons karena halaman error yang ramah masih dapat menyembunyikan mutasi selesai. Uji perilaku tombol kembali bila memakai token per-request, serta konkurensi bila rotasi token dapat membatalkan tab lain yang terbuka. Tindakan sensitif seperti mengubah metode recovery dapat memerlukan reauthentication selain kontrol CSRF.
Catat apakah request ditolak membuat audit event tanpa membuat business event terlindungi. Uji validasi token sebelum pemrosesan mahal dan sebelum asynchronous enqueue. Ini mencegah forgery menjadi jalur konsumsi resource meski mutasi akhirnya gagal.
Logging CSRF tidak boleh menyimpan nilai token atau identifier sesi. Catat kategori route, kategori kegagalan verifikasi, sinyal asal browser, dan correlation ID saja. Pengiriman tidak valid berulang dapat menunjukkan integrasi klien rusak, bukan serangan, sehingga pasangkan telemetri dengan versi rilis dan diagnosis dukungan. Jangan mengembalikan detail token dalam respons error. Setelah pembaruan sesi, uji perilaku token lama sesuai kebijakan dan token baru diterbitkan melalui channel respons yang dimaksud.
Review akhir mengikat setiap mutasi terlindungi pada satu penolakan teramati dan satu alur browser yang dimaksud. Output diharapkan: bukti hilang, lintas situs, atau basi tidak membuat business write. Kasus tepi: tab bersamaan menyimpan generasi token berbeda; verifikasi perilaku terdokumentasi. Tutup hanya saat kebijakan cookie, validasi token, dan bukti audit selaras pada route terdeploy.