TDCTF Academy Logo TDCTF ACADEMY

Cross-Site Request Forgery (CSRF)

Pendahuluan

Cross-Site Request Forgery (CSRF, dibaca "sea-surf") adalah serangan yang memaksa pengguna yang telah terautentikasi untuk menjalankan aksi yang tidak diinginkan pada aplikasi web tempat mereka sedang login. Penyerang memanfaatkan kepercayaan aplikasi terhadap browser korban - karena browser secara otomatis menyertakan cookie sesi dalam setiap request ke domain target, penyerang dapat memalsukan request tanpa mengetahui kredensial korban.

CSRF berbeda dengan XSS: dalam XSS, penyerang mengeksploitasi kepercayaan korban terhadap situs; dalam CSRF, penyerang mengeksploitasi kepercayaan situs terhadap browser korban.

Cara Kerja CSRF

  1. Korban login ke aplikasi target (misal: bank.example.com) dan mendapat cookie sesi.
  2. Penyerang menyiapkan halaman jahat di situs lain (misal: evil.com).
  3. Korban mengunjungi situs penyerang saat masih login ke aplikasi target.
  4. Browser korban mengirimkan request ke aplikasi target, termasuk cookie sesi secara otomatis.
  5. Aplikasi target menerima request karena cookie valid, tanpa tahu bahwa request dipalsukan.

Contoh Serangan

Serangan via Tag <img>

Penyerang dapat memicu request GET dengan menyisipkan tag gambar:

<img src="https://bank.example.com/transfer?to=attacker&amount=10000" width="0" height="0">

Saat browser memuat halaman, ia akan melakukan GET request ke URL tersebut. Jika aplikasi menggunakan parameter query untuk transfer, request akan dieksekusi.

Serangan via Form Otomatis

Untuk request POST, penyerang menggunakan form HTML yang disubmit otomatis via JavaScript:

<form action="https://bank.example.com/transfer" method="POST" id="csrf-form">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="10000">
</form>
<script>document.getElementById('csrf-form').submit();</script>

CSRF Token Bypass

Beberapa implementasi CSRF token rentan terhadap bypass:

  • Token dalam cookie: Jika token disimpan dalam cookie dan dikirim bersama request, penyerang bisa menebak atau menggunakan teknik CSRF + cookie injection.
  • Token statis: Token yang sama untuk semua sesi atau tidak berubah.
  • Token leakage: Token bocor melalui referrer header, log server, atau XSS.
  • HTTP Method override: Mengubah metode dari POST ke GET dengan header X-HTTP-Method-Override: POST.
  • Token diabaikan untuk metode tertentu: Beberapa aplikasi hanya memvalidasi token untuk POST tapi tidak untuk PUT/DELETE.

Dampak CSRF

  • Perubahan Data: Transfer dana, ubah email/password, hapus akun.
  • Aksi Administrator: Pada aplikasi dengan hak admin, CSRF dapat membuat akun baru, menghapus resource, atau mengubah konfigurasi.
  • Privilege Escalation: Mengubah role pengguna.
  • Perubahan State: Melakukan vote, posting komentar, follow akun media sosial.

Dampak CSRF bergantung pada fungsi yang dieksploitasi. Pada aplikasi perbankan, dampaknya bisa kerugian finansial. Pada aplikasi email, bisa pembajakan akun.

Mitigasi

1. CSRF Token (Synchronizer Token Pattern)

Mekanisme pertahanan utama. Server membangkitkan token unik per sesi atau per request yang:

  • Disertakan dalam form sebagai field tersembunyi
  • Tidak bisa ditebak oleh penyerang
  • Tidak disimpan dalam cookie
  • Divalidasi server untuk setiap request state-changing
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="8a2b9c...random...">
...
</form>

2. SameSite Cookies

Attribute SameSite pada cookie mencegah cookie dikirim pada request lintas situs.

  • SameSite=Strict: Cookie tidak dikirim untuk request dari origin berbeda (aman, tapi bisa memutus navigasi legitimate).
  • SameSite=Lax (default modern browser): Cookie dikirim untuk navigasi top-level GET, tidak untuk POST atau request dari script.
  • SameSite=None: Cookie dikirim lintas situs (harus dengan Secure flag).
Set-Cookie: sessionid=abc123; SameSite=Lax; Secure; HttpOnly

3. Custom Header

Mewajibkan header khusus (misal X-Requested-With: XMLHttpRequest) untuk request state-changing. Karena penyerang tidak bisa menambahkan header khusus dari origin berbeda tanpa izin CORS, ini efektif untuk memblokir CSRF.

4. Re-Authentication

Meminta pengguna memasukkan password atau melakukan verifikasi tambahan (CAPTCHA, OTP, biometric) untuk aksi sensitif seperti transfer dana besar, perubahan email, atau penghapusan akun.

Mengirim CSRF token dalam cookie dan juga sebagai request parameter/header. Server memvalidasi bahwa nilai dari cookie cocok dengan nilai dari request.

6. Origin / Referer Header Validation

Memeriksa header Origin atau Referer untuk memastikan request berasal dari domain yang sah. Tidak sepenuhnya reliable karena header bisa dihilangkan atau dimanipulasi oleh ekstensi/proxy.

Kesimpulan

CSRF adalah serangan yang memanfaatkan otentikasi implicit melalui cookie. Strategi pertahanan berlapis menggunakan CSRF token, SameSite cookies, dan custom header memberikan perlindungan komprehensif. Saat ini, SameSite=Lax sebagai default browser modern sudah mengurangi permukaan serangan CSRF secara signifikan, tetapi CSRF token tetap direkomendasikan sebagai pertahanan utama.

PADA HALAMAN INI