Apa Itu CSRF (Cross-Site Request Forgery)? Cara Kerja, Dampak, dan Pencegahannya

Bayangkan skenario ini: Anda baru saja login ke aplikasi mobile banking untuk mengecek saldo. Setelah selesai, Anda membuka tab baru dan mengunjungi sebuah forum diskusi yang tampak biasa saja. Tanpa Anda sadari, forum tersebut mengirimkan permintaan transfer uang ke bank Anda – dan karena sesi login Anda masih aktif, transfer itu berhasil diproses. Inilah yang disebut serangan Cross-Site Request Forgery (CSRF).

CSRF adalah salah satu kerentanan web yang paling sering diremehkan. Tidak sepopuler SQL Injection atau XSS, tetapi dampaknya bisa sama fatalnya. Berdasarkan OWASP Top 10 edisi 2017, CSRF masuk dalam daftar sepuluh besar ancaman web paling berbahaya. Meskipun di edisi 2021 CSRF digabungkan ke dalam kategori yang lebih luas, teknik serangan ini masih sangat relevan dan terus ditemukan di aplikasi modern.

Artikel ini akan membahas secara lengkap: apa itu CSRF, bagaimana mekanisme serangannya, dampak nyata yang bisa terjadi, perbedaannya dengan XSS, dan yang paling penting – bagaimana cara mencegahnya. Semua dijelaskan dengan bahasa yang mudah dipahami oleh pemula sekalipun.

Apa Itu Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) adalah serangan yang memaksa pengguna terautentikasi untuk melakukan tindakan yang tidak diinginkan di suatu aplikasi web. Serangan ini memanfaatkan credential pengguna yang otomatis dikirim browser. Browser menyertakan session cookie di setiap permintaan ke domain tertentu tanpa membedakan apakah permintaan itu disengaja oleh pengguna atau tidak.

Istilah “cross-site” mengacu pada skenario di mana serangan berasal dari satu situs (situs jahat) tetapi targetnya adalah situs lain (situs korban). Istilah “request forgery” berarti pemalsuan permintaan – penyerang membuat pengguna tanpa sadar mengirimkan permintaan HTTP yang tampak sah ke aplikasi target.

Yang membuat CSRF sangat berbahaya adalah sifatnya yang transparent bagi korban. Korban tidak perlu mengklik tombol mencurigakan atau mengunduh file berbahaya. Cukup dengan mengunjungi halaman web yang telah disusupi kode CSRF, serangan bisa langsung tereksekusi dalam hitungan milidetik. OWASP secara konsisten menempatkan CSRF sebagai salah satu risiko keamanan aplikasi web yang perlu mendapat perhatian serius dari developer.

Bagaimana Cara Kerja Serangan CSRF?

Untuk memahami CSRF, kita perlu memahami bagaimana browser menangani session pengguna. Ketika Anda login ke sebuah situs web, server memberikan session cookie ke browser Anda. Cookie ini berfungsi sebagai “kartu identitas” yang membuktikan bahwa Anda sudah terautentikasi. Setiap kali Anda mengakses halaman di situs tersebut, browser secara otomatis mengirimkan cookie itu bersama permintaan HTTP.

Serangan CSRF mengeksploitasi mekanisme ini. Penyerang membuat halaman web jahat yang berisi kode HTML atau JavaScript yang secara otomatis mengirimkan permintaan ke aplikasi target. Karena browser korban masih menyimpan cookie yang valid, permintaan palsu itu diperlakukan seolah-olah sah oleh server.

Contoh Skenario Serangan CSRF

Mari kita lihat contoh konkret. Bayangkan sebuah aplikasi perbankan online bernama SecureBank yang memiliki endpoint untuk transfer dana dengan URL seperti ini:

POST https://securebank.com/transfer
Body: amount=10000000&to_account=1234567890

Penyerang kemudian membuat halaman web di domain jahat yang berisi form tersembunyi seperti ini:

<form action="https://securebank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="50000000">
  <input type="hidden" name="to_account" value="9876543210">
</form>
<script>document.forms[0].submit();</script>

Ketika korban yang masih login ke SecureBank mengunjungi halaman jahat tersebut, form otomatis terkirim ke SecureBank. Browser korban menyertakan session cookie yang masih valid. Server SecureBank melihat permintaan ini sebagai permintaan sah dari pengguna yang terautentikasi – dan transfer pun diproses.

Yang perlu diperhatikan: serangan ini tidak memerlukan JavaScript. CSRF juga bisa dilakukan dengan tag HTML biasa seperti <img>, <script>, atau <link> yang secara otomatis membuat permintaan GET ke URL target.

Apa Dampak Serangan CSRF terhadap Aplikasi Web?

Dampak CSRF sangat bergantung pada jenis aplikasi yang diserang dan tingkat hak akses pengguna yang menjadi korban. Semakin tinggi privilege korban di aplikasi target, semakin besar potensi kerusakan yang bisa ditimbulkan.

Dampak pada Aplikasi Keuangan

Di aplikasi perbankan atau e-wallet, CSRF bisa digunakan untuk mentransfer dana dari rekening korban ke rekening penyerang. Berdasarkan laporan OWASP, beberapa celah CSRF di aplikasi finansial ditemukan bisa mentransfer seluruh saldo pengguna hanya dengan satu permintaan HTTP yang dipalsukan. Satu klik – atau bahkan tanpa klik – sudah cukup untuk mengosongkan rekening.

Dampak pada Aplikasi Enterprise

Di aplikasi perusahaan, CSRF bisa berdampak pada perubahan data penting, pembuatan akun baru dengan hak administrator, atau perubahan konfigurasi sistem. Jika penyerang berhasil mengeksploitasi CSRF pada akun administrator, mereka bisa mengubah password, menghapus data produksi, atau mengubah pengaturan keamanan tanpa terdeteksi.

Dampak pada CMS dan Aplikasi Web Umum

Content Management System (CMS) seperti WordPress sering menjadi target CSRF. Penyerang bisa memanfaatkan CSRF untuk membuat akun admin baru, mengubah konten halaman, atau menyisipkan kode berbahaya ke dalam postingan. WordPress sendiri secara aktif merilis pembaruan keamanan untuk menambal kerentanan CSRF yang ditemukan di plugin dan tema populer.

Yang perlu diingat: CSRF tidak mencuri data. Serangan ini tidak bisa membaca respons dari server. Tujuannya murni untuk memaksa server melakukan tindakan tertentu atas nama korban. Namun jika digabungkan dengan kerentanan lain seperti XSS, dampaknya bisa berlipat ganda.

Apa Perbedaan CSRF dengan XSS (Cross-Site Scripting)?

CSRF dan XSS sering disalahartikan sebagai hal yang sama, padahal keduanya adalah kerentanan yang sangat berbeda. Memahami perbedaan ini penting untuk menentukan strategi mitigasi yang tepat.

Cross-Site Scripting (XSS) adalah kerentanan di mana penyerang bisa menyuntikkan kode JavaScript berbahaya ke dalam halaman web yang dilihat oleh pengguna lain. XSS menargetkan client-side – kode berbahaya dieksekusi di browser korban dan bisa mencuri cookie, token, atau data sensitif lainnya.

CSRF sebaliknya, menargetkan server-side. Penyerang tidak perlu menyuntikkan kode ke aplikasi target. Mereka cukup memanfaatkan fakta bahwa browser korban otomatis mengirimkan cookie ke domain yang relevan. CSRF tidak bisa membaca respons server – hanya bisa mengirim permintaan.

Berikut perbandingan ringkas antara keduanya: XSS mengeksekusi kode di browser korban dan bisa mencuri data, sementara CSRF mengirimkan permintaan ke server korban dan tidak bisa membaca respons. XSS membutuhkan celah injeksi di aplikasi target, sedangkan CSRF bisa dilakukan dari situs manapun selama korban memiliki sesi aktif. Jika sebuah aplikasi memiliki kerentanan XSS, maka semua perlindungan CSRF bisa dibypass karena penyerang bisa membaca token CSRF melalui JavaScript.

Bagaimana Cara Mencegah Serangan CSRF?

Pencegahan CSRF membutuhkan pendekatan berlapis. Tidak ada satu solusi tunggal yang sempurna untuk semua skenario. Berdasarkan panduan OWASP CSRF Prevention Cheat Sheet, berikut adalah metode-metode yang direkomendasikan.

1. Anti-CSRF Token (Synchronizer Token Pattern)

Ini adalah metode pencegahan CSRF yang paling umum dan paling direkomendasikan. Server menghasilkan token acak yang unik untuk setiap sesi pengguna atau setiap permintaan. Token ini disematkan di dalam form HTML sebagai hidden field. Saat form dikirim, server memvalidasi apakah token yang diterima cocok dengan token yang diberikan.

Penyerang tidak bisa menebak atau mendapatkan token ini. Ada tiga alasan utamanya: token bersifat acak dan unik untuk setiap sesi. Token hanya bisa diakses dari halaman yang sama (same-origin). Server memvalidasi token di setiap permintaan yang mengubah status seperti POST, PUT, atau DELETE. Framework modern seperti Laravel, Django, Spring Security, dan Express.js sudah menyediakan fitur CSRF token secara built-in.

2. SameSite Cookie Attribute

Atribut SameSite pada cookie adalah mekanisme pertahanan CSRF yang relatif baru namun sangat efektif. Atribut ini memberi tahu browser untuk tidak mengirimkan cookie ketika permintaan berasal dari situs yang berbeda (cross-site). Ada tiga nilai yang bisa digunakan:

SameSite=Strict: Cookie tidak akan dikirim untuk semua permintaan cross-site. Paling aman tetapi bisa mengganggu pengalaman pengguna karena tautan dari email atau situs lain tidak akan membawa sesi login.
SameSite=Lax: Cookie dikirim untuk navigasi tingkat atas (top-level navigation) dengan metode GET, tetapi tidak untuk permintaan POST dari situs lain. Ini adalah default di browser modern seperti Chrome dan Firefox sejak 2020.
SameSite=None: Cookie dikirim untuk semua permintaan cross-site. Harus dikombinasikan dengan atribut Secure (HTTPS only). Tidak direkomendasikan kecuali memang diperlukan.

Pengaturan SameSite=Lax sudah menjadi standar di browser modern dan memberikan perlindungan CSRF yang signifikan tanpa perlu perubahan kode aplikasi. Namun metode ini sebaiknya digunakan sebagai lapisan tambahan, bukan satu-satunya pertahanan.

3. Validasi Origin dan Referer Header

Setiap permintaan HTTP menyertakan header Origin atau Referer yang menunjukkan dari mana permintaan berasal. Server bisa memvalidasi header ini untuk memastikan permintaan berasal dari domain yang sah. Jika permintaan transfer dana berasal dari situs-jahat.com tetapi seharusnya dari securebank.com, server bisa langsung menolaknya.

Namun metode ini memiliki kelemahan: beberapa browser atau pengaturan privasi bisa menghapus header Referer. Header Origin juga tidak selalu dikirim untuk semua jenis permintaan. Oleh karena itu, validasi Origin/Referer sebaiknya digunakan sebagai lapisan pertahanan tambahan, bukan pengganti CSRF token.

4. Custom Request Header

Metode ini memanfaatkan kebijakan same-origin browser. Browser hanya mengizinkan JavaScript untuk menambahkan custom header pada permintaan ke domain yang sama. Jika server mewajibkan adanya header khusus (misalnya X-Requested-With: XMLHttpRequest) untuk semua permintaan yang mengubah state, maka permintaan CSRF dari situs lain akan otomatis gagal.

Metode ini sangat populer di API modern yang menggunakan token Bearer di header Authorization. Karena browser tidak mengirimkan header Authorization secara otomatis, API berbasis token sudah kebal terhadap CSRF secara default.

Pertanyaan Umum tentang CSRF

Apakah aplikasi yang hanya menggunakan POST request tetap rentan CSRF?

Ya, justru aplikasi yang menggunakan POST untuk operasi sensitif adalah target utama CSRF. Penyerang bisa membuat form HTML otomatis dengan method POST yang mengirimkan data ke endpoint target. Mengganti method dari GET ke POST bukanlah mitigasi CSRF yang efektif.

Apakah HTTPS melindungi dari CSRF?

Tidak. HTTPS mengenkripsi komunikasi antara browser dan server, tetapi tidak mencegah browser mengirimkan cookie ke domain yang relevan. Serangan CSRF tetap bisa terjadi di atas koneksi HTTPS karena browser tetap mengirimkan session cookie secara otomatis.

Apakah REST API rentan terhadap CSRF?

Tergantung pada metode autentikasinya. API yang menggunakan token di header Authorization (seperti JWT Bearer token) kebal terhadap CSRF karena browser tidak mengirimkan header Authorization secara otomatis. Namun API yang menggunakan cookie-based authentication tetap rentan dan membutuhkan perlindungan CSRF.

Bagaimana cara mengecek apakah aplikasi saya rentan CSRF?

Langkah pertama adalah memeriksa apakah endpoint yang mengubah state (POST, PUT, DELETE) memiliki mekanisme anti-CSRF. Periksa apakah form mengandung hidden token CSRF. Gunakan browser developer tools untuk memeriksa apakah cookie session memiliki atribut SameSite. Tools seperti Burp Suite dan OWASP ZAP juga bisa digunakan untuk menguji kerentanan CSRF secara otomatis.

Kesimpulan

Cross-Site Request Forgery (CSRF) adalah kerentanan yang memanfaatkan kepercayaan aplikasi web terhadap browser pengguna yang terautentikasi. Meskipun tidak sepopuler SQL Injection atau XSS, dampak CSRF bisa sama merusaknya – terutama pada aplikasi yang menangani data sensitif atau transaksi keuangan.

Pertahanan terhadap CSRF membutuhkan pendekatan berlapis. Anti-CSRF token tetap menjadi standar emas yang direkomendasikan OWASP. Atribut SameSite cookie memberikan lapisan perlindungan tambahan di sisi browser. Validasi Origin/Referer header dan custom request header melengkapi strategi pertahanan secara keseluruhan.

Untuk developer, langkah paling praktis adalah menggunakan framework modern yang sudah menyediakan perlindungan CSRF secara built-in. Framework seperti Laravel, Django, Ruby on Rails, dan Spring Security memiliki mekanisme CSRF token yang aktif secara default. Untuk aplikasi React, Angular, atau Vue yang menggunakan API token-based, pastikan token disimpan dengan aman dan tidak menggunakan cookie-based authentication jika tidak diperlukan.

Keamanan web adalah tanggung jawab bersama. Memahami CSRF, cara kerjanya, dan metode pencegahannya adalah langkah penting bagi setiap developer, security engineer, dan siapa pun yang peduli dengan keamanan aplikasi web. Dengan menerapkan proteksi yang tepat, serangan CSRF bisa sepenuhnya dicegah sebelum sempat menimbulkan kerusakan.

👉 Mulai Konsistensi Belajar SEKARANG!