Praktikum Keamanan Web: Cross-Site Request Forgery (CSRF) 😱🛡️

Source: Dev.to

Pendahuluan

Halo, teman‑teman mahasiswa! Selamat datang di praktikum tentang Cross‑Site Request Forgery (CSRF), salah satu serangan web yang licik. Bayangkan kamu sedang login di bank online, lalu membuka tab lain ke situs jahat. Tanpa sadar, situs jahat dapat “memaksa” browser kamu mengirim request ke bank untuk mentransfer uang ke hacker, padahal kamu tidak mengklik apa‑apa. Ini terjadi karena browser secara otomatis mengirim cookie autentikasi pada request ke domain lain.

CSRF adalah pemalsuan permintaan dari situs lain yang memanfaatkan kepercayaan browser terhadap cookie session.

Cara Kerja CSRF

Syarat Utama

1. User sudah login – terdapat cookie session yang valid.
2. Aksi penting (misalnya transfer uang, ubah password, delete akun) menggunakan method GET atau POST tanpa proteksi.
3. Browser otomatis mengirim cookie ke domain asal pada setiap request.

Alur Serangan (contoh klasik)

1. Victim yang sudah login ke situs target mengunjungi situs jahat.
2. Situs jahat memuat elemen (misalnya gambar atau form tersembunyi) yang mengirim request ke situs target.
3. Browser victim mengirim request beserta cookie session, sehingga aksi berbahaya dijalankan tanpa sepengetahuan victim.

Contoh Kerentanan

1. Transfer Bank dengan GET

GET http://bank.com/transfer?jumlah=1000000&rekening_tujuan=12345678 HTTP/1.1
Host: bank.com
Cookie: session=abcd1234

Situs jahat dapat menyisipkan gambar tersembunyi:

![](http://bank.com/transfer?jumlah=5000000&rekening_tujuan=hacker123)

Ketika victim membuka halaman jahat, browser otomatis mengirim request transfer ke akun hacker.

2. Form Rentan (POST tanpa proteksi)

<form action="/ubah-email" method="POST">
    <input type="email" name="email" value="hacker@example.com">
    <button type="submit">Simpan</button>
</form>

Situs jahat:

<script>
    document.getElementById('jahat').submit();
</script>

Victim yang membuka halaman jahat akan secara otomatis mengirimkan form tersebut, sehingga email akun diubah menjadi milik hacker.

3. Aksi “Like” dengan GET

Request contoh: GET /post?id=123&action=like.
Situs jahat dapat menambahkan tag gambar:

![](http://target.com/post?id=123&action=like)

Mekanisme Perlindungan

CSRF Token (paling umum & kuat)

1. Server menghasilkan token unik per session atau per form.
2. Token disertakan dalam form (sebagai hidden input) atau header khusus.
3. Server memvalidasi token sebelum memproses request.

<form action="/simpan" method="POST">
    <input type="hidden" name="csrf_token" value="RANDOM_TOKEN">
    <button type="submit">Simpan</button>
</form>

Jika token tidak cocok atau tidak ada, server menolak request.

SameSite Cookie

Set cookie dengan atribut SameSite=Lax atau SameSite=Strict sehingga browser tidak mengirim cookie pada request cross‑site.

Set-Cookie: session=abcd1234; SameSite=Strict; Secure; HttpOnly

Praktik Baik Lainnya

• Gunakan POST untuk aksi yang mengubah state, hindari GET.
• Double Submit Cookie: kirim token baik sebagai cookie maupun sebagai parameter form.
• Manfaatkan proteksi bawaan framework (Laravel, Django, Spring Security, dll.) yang secara otomatis menambahkan dan memvalidasi token.

Bonus: CSRF vs XSS 🆚

Praktik dan Lab

• Buat form transfer rentan di PHP dan uji serangan CSRF dengan tag gambar.
• Tambahkan CSRF token manual dan uji kembali; request seharusnya gagal.
• Coba lab gratis di PortSwigger Web Security Academy (search “CSRF”).

Diskusi

• Mengapa banyak bank mengkombinasikan token CSRF dengan OTP?
• Bagaimana cara memastikan semua endpoint state‑changing terlindungi?

Selamat berpraktikum! Dengan memahami CSRF dan menerapkan proteksi yang tepat, aplikasi web kamu akan lebih aman seperti brankas bank. Selalu lindungi aksi yang mengubah state, dan terus kembangkan kebiasaan coding yang aman. 🎉🔐