Pengertian CSRF dan Cara Mencegahnya

CSRF (Cross-Site Request Forgery) adalah serangan yang menipu browser pengguna agar mengirim permintaan ke situs tepercaya tanpa sepengetahuan pemiliknya. Karena browser otomatis menyertakan cookie sesi, situs target mengira permintaan itu sah dan menjalankan aksinya, misalnya mengganti email atau mentransfer dana. Artikel ini menjelaskan cara kerja CSRF secara konseptual dan langkah pencegahan yang direkomendasikan OWASP dan MDN.

Apa Itu CSRF dan Bagaimana Cara Kerjanya?

Menurut MDN, serangan CSRF mungkin terjadi bila tiga kondisi terpenuhi sekaligus: situs memakai permintaan HTTP untuk mengubah status di server, situs hanya mengandalkan cookie untuk mengautentikasi permintaan itu, dan semua parameter permintaan dapat ditebak oleh penyerang.

Alurnya sebagai berikut. Pengguna sudah login ke situs sah, misalnya aplikasi perbankan atau panel admin, sehingga browser menyimpan cookie sesi. Ia lalu membuka halaman lain yang dikendalikan penyerang, entah lewat tautan di pesan atau iklan. Halaman itu memicu permintaan ke situs sah, dan browser melampirkan cookie sesi seperti biasa. Server tidak bisa membedakan permintaan itu dari aksi yang memang dimaksudkan pengguna.

Perlu dicatat, penyerang tidak bisa membaca balasan dari server. Targetnya adalah aksi yang mengubah status, bukan pencurian data langsung. Contoh aksi yang rawan adalah ganti kata sandi atau email, tambah pengguna admin, transfer dana, dan hapus data.

Dampak Serangan CSRF

Dampaknya bergantung pada hak akses korban. Jika korban pengguna biasa, penyerang dapat mengubah data profil atau memicu transaksi. Jika korban administrator, aksi yang terpicu bisa berupa pembuatan akun admin baru atau perubahan konfigurasi yang membuka jalan ke pengambilalihan situs. Karena permintaan datang dari browser korban yang sudah terautentikasi, jejaknya di log tampak seperti aktivitas normal pengguna tersebut.

Cara Mencegah CSRF

OWASP CSRF Prevention Cheat Sheet merekomendasikan beberapa pertahanan yang saling melengkapi.

Token CSRF (synchronizer token)

Server membuat token acak yang terikat pada sesi pengguna dan mewajibkannya pada setiap permintaan yang mengubah status. Token dikirim lewat kolom form tersembunyi atau header khusus, bukan lewat cookie atau URL. Penyerang lintas situs tidak dapat mengetahui nilainya. Untuk aplikasi tanpa state di server, OWASP menyarankan varian double-submit cookie yang ditandatangani (signed), dan tidak menyarankan varian naif karena dapat dikalahkan bila penyerang mampu menulis cookie di domain Anda.

Cookie dengan atribut SameSite

Atribut SameSite mengatur apakah cookie ikut terkirim pada permintaan lintas situs. Mode Strict tidak pernah mengirim cookie lintas situs. Mode Lax hanya mengirimnya pada navigasi tingkat atas dengan metode aman seperti GET, sehingga aksi pengubah status tidak boleh dilakukan lewat GET. Menurut OWASP, SameSite adalah lapisan pertahanan tambahan, bukan solusi tunggal. Atribut ini bekerja per situs, bukan per origin, sehingga subdomain saudara tetap perlu dipercaya.

Verifikasi Origin dan Fetch Metadata

Server dapat memeriksa header Origin, atau Referer bila Origin tidak ada, dan membandingkannya dengan origin aplikasi sendiri. Header Sec-Fetch-Site dari browser juga dapat dipakai untuk menolak permintaan lintas situs yang mengubah status. OWASP mengingatkan agar pemeriksaan ini punya fallback untuk browser lama dan tidak pernah menganggap nilai null sebagai tepercaya.

Permintaan yang bukan simple request

Untuk API, mewajibkan header khusus seperti X-CSRF-Token atau tipe konten JSON membuat permintaan lintas origin diperiksa lebih dulu oleh browser lewat preflight. Pengaturan CORS yang terlalu longgar, misalnya mengizinkan kredensial untuk banyak origin, melemahkan perlindungan ini.

Praktik pendukung

• Jangan pernah mengubah status lewat permintaan GET.
• Gunakan fitur CSRF bawaan framework Anda dan jangan membuat sendiri bila tidak perlu.
• Minta autentikasi ulang atau konfirmasi tambahan untuk aksi sensitif seperti ganti kata sandi.
• Wajibkan HTTPS di seluruh aplikasi.

Cara Memeriksa Apakah Aplikasi Anda Rentan

MDN menyarankan langkah awal yang sederhana: daftarkan setiap permintaan yang mengubah status dan mengandalkan cookie sesi, lalu pastikan masing-masing dilindungi minimal satu pertahanan utama, yaitu token CSRF, permintaan yang bukan simple request, atau pemeriksaan Fetch Metadata. Pada tinjauan kode, perhatikan juga pola berikut:

• endpoint yang mengubah data tetapi menerima metode GET;
• form yang tidak memuat token atau endpoint yang tidak memvalidasinya;
• cookie sesi tanpa atribut SameSite atau dengan SameSite=None tanpa alasan kuat;
• konfigurasi CORS yang mengizinkan kredensial untuk daftar origin yang terlalu luas.

OWASP juga menjelaskan CSRF sisi klien, yaitu ketika masukan yang dikendalikan penyerang membuat JavaScript aplikasi sendiri mengirim permintaan palsu. Varian ini dapat melewati token dan SameSite, sehingga tujuan permintaan di kode klien tidak boleh ditentukan oleh masukan yang tidak divalidasi. Pengujian seperti ini hanya dilakukan pada aplikasi milik sendiri atau dengan izin tertulis pemiliknya.

Hubungan CSRF dengan XSS

OWASP menegaskan bahwa XSS dapat mengalahkan semua mitigasi CSRF: skrip yang berjalan di origin Anda dapat membaca token dan mengirim permintaan seolah-olah dari halaman Anda sendiri. Jadi token CSRF tetap diperlukan, tetapi tidak menggantikan pencegahan cross-site scripting (XSS). Pembahasan lain yang berkaitan dengan perlindungan halaman dari manipulasi tampilan ada di artikel clickjacking.

Pertanyaan yang Sering Diajukan

Apa perbedaan CSRF dan XSS?

XSS menyisipkan skrip ke dalam halaman situs target sehingga berjalan di dalamnya. CSRF tidak perlu menyisipkan apa pun ke situs target; ia memanfaatkan kepercayaan situs pada cookie browser dan memicu aksi dari situs lain.

Apakah API dengan token di header otomatis aman dari CSRF?

Umumnya risikonya jauh lebih kecil, karena browser tidak melampirkan header kustom secara otomatis. Namun API yang tetap mengandalkan cookie untuk autentikasi harus diperlakukan seperti aplikasi web biasa, dan aturan di keamanan API tetap berlaku.

Apakah SameSite saja sudah cukup?

Belum. OWASP menyebutnya sebagai lapisan tambahan. Aksi lewat GET, subdomain yang tidak dipercaya, dan jenis CSRF sisi klien dapat melewatinya, sehingga token atau verifikasi Origin tetap diperlukan.

Apakah pengguna biasa bisa melindungi diri dari CSRF?

Sebagian. Keluar dari akun sensitif setelah selesai dan tidak membuka tautan mencurigakan saat masih login membantu, tetapi pertahanan utama ada di sisi pengembang aplikasi.

Kesimpulan

CSRF bukan soal mencuri kata sandi, melainkan menyalahgunakan sesi login yang sedang aktif. Kombinasi token CSRF, cookie SameSite, verifikasi Origin atau Fetch Metadata, dan HTTPS menutup celah ini dengan baik. Jika tim Anda ingin memahami dan menguji pertahanan semacam ini secara terstruktur dan sah, kenali program pelatihan Linuxhackingid untuk tim.