Di era digital seperti sekarang, hampir semua aktivitas dilakukan melalui website dan aplikasi online. Mulai dari mengakses media sosial, berbelanja, mengelola akun, menggunakan layanan perbankan, hingga mengakses sistem perusahaan.
Untuk melindungi akun, banyak pengguna berfokus pada penggunaan password yang kuat.
Password memang penting. Namun, keamanan sebuah akun tidak hanya bergantung pada password.
Ada berbagai jenis serangan yang dapat mengeksploitasi kelemahan aplikasi web dan mekanisme autentikasi pengguna. Salah satunya adalah CSRF Attack atau Cross-Site Request Forgery.
Serangan ini menarik karena attacker tidak selalu perlu mengetahui password korban.
Dalam skenario tertentu, attacker dapat membuat korban secara tidak sadar mengirimkan request ke website yang sedang digunakan, sementara browser korban masih memiliki kredensial atau session yang valid.
Akibatnya, sebuah tindakan dapat dilakukan menggunakan hak akses korban.
Mulai dari mengubah pengaturan akun, mengubah data tertentu, hingga melakukan transaksi—tergantung pada vulnerability dan fungsi yang tersedia pada aplikasi target.
Lalu, apa sebenarnya CSRF Attack?
Bagaimana cara kerjanya?
Mengapa CSRF berbahaya?
Dan bagaimana developer dapat mencegah Cross-Site Request Forgery?
Mari kita bahas dari dasar.
Apa Itu CSRF Attack?
CSRF (Cross-Site Request Forgery) adalah jenis kerentanan keamanan pada aplikasi web yang memungkinkan attacker memengaruhi browser pengguna untuk mengirimkan request yang tidak diinginkan ke website tempat pengguna sedang terautentikasi.
Sederhananya, attacker mencoba membuat browser korban melakukan sebuah tindakan tanpa persetujuan korban.
Hal penting yang perlu dipahami adalah:
CSRF bukan berarti attacker mengetahui password korban.
Serangan ini memanfaatkan fakta bahwa browser dapat secara otomatis menyertakan informasi autentikasi tertentu ketika mengirim request ke sebuah website.
Contohnya, pengguna sedang login ke sebuah website.
Kemudian pengguna mengunjungi website lain yang telah disiapkan oleh attacker.
Website tersebut mencoba memicu request menuju website pertama.
Jika aplikasi target memiliki perlindungan CSRF yang lemah atau tidak memadai, request tersebut berpotensi dianggap sebagai request yang sah.
Bagaimana CSRF Berbeda dengan Pencurian Password?
Ini merupakan salah satu hal yang sering membuat pemula bingung.
Dalam pencurian password, attacker berusaha mendapatkan:
Username + Password → Login ke akun korban
Sedangkan dalam CSRF, skenarionya berbeda:
Korban sudah login → Browser korban memiliki autentikasi → Attacker memicu request → Server menerima request
Jadi, attacker tidak selalu perlu mengetahui password korban.
Inilah yang membuat CSRF Attack menjadi topik penting dalam pembelajaran web security.
Bagaimana Cara Kerja CSRF?
Untuk memahami CSRF dengan mudah, bayangkan terdapat tiga pihak:
- Korban atau User
- Website target
- Attacker
Korban sudah login ke website target.
Kemudian attacker mencoba membuat browser korban mengirimkan request tertentu ke website tersebut.
Secara sederhana:
Attacker → Memicu request → Browser korban → Website target
Jika website target tidak memiliki mekanisme validasi yang tepat, server dapat menganggap request tersebut berasal dari tindakan pengguna yang sah.
Mari kita lihat alurnya secara lebih detail.
1. Korban Login ke Website
Pertama, korban login ke sebuah website.
Misalnya:
website-target.com
Setelah proses login berhasil, server memberikan mekanisme autentikasi kepada browser, misalnya melalui session cookie.
Browser kemudian menggunakan informasi tersebut ketika berkomunikasi kembali dengan website.
Secara sederhana:
User Login → Server membuat session → Browser menyimpan cookie → User dapat mengakses akun
Selama session masih valid, pengguna tidak perlu memasukkan password pada setiap request.
2. Attacker Membuat Halaman Berbahaya
Selanjutnya, attacker memiliki website atau halaman yang dirancang untuk memicu request tertentu ke website target.
Halaman tersebut dapat disebarkan melalui berbagai media.
Misalnya:
- Website
- Pesan
- Media sosial
- Link tertentu
Yang perlu dipahami adalah attacker berusaha membuat korban mengunjungi atau berinteraksi dengan konten yang memicu request.
3. Korban Membuka Halaman Tersebut
Korban kemudian membuka halaman yang dikendalikan attacker.
Korban mungkin mengira halaman tersebut tidak berbahaya.
Namun, di belakang layar, halaman tersebut dapat mencoba memicu request ke website target.
Contohnya secara konseptual:
Browser → Request ke website attacker
kemudian halaman tersebut memicu:
Browser → Request ke website target
Jika aplikasi target rentan terhadap CSRF, request tersebut dapat diproses.
4. Browser Mengirimkan Informasi Autentikasi
Ini adalah bagian penting dalam memahami cara kerja CSRF.
Browser memiliki mekanisme untuk mengelola cookie.
Dalam kondisi tertentu, cookie yang relevan dapat ikut dikirim ketika browser melakukan request ke domain terkait.
Jika cookie tersebut digunakan oleh aplikasi sebagai bukti autentikasi dan aplikasi tidak memiliki perlindungan CSRF yang memadai, server dapat menganggap request tersebut sebagai request dari pengguna yang sedang login.
Dengan kata lain:
Browser memiliki session yang valid → Request dikirim → Server melihat autentikasi → Request diproses
Masalahnya, server belum tentu mengetahui apakah request tersebut benar-benar berasal dari tindakan yang sengaja dilakukan pengguna.
5. Server Memproses Request
Jika endpoint aplikasi tidak memiliki validasi yang memadai, server dapat menerima request tersebut.
Misalnya sebuah aplikasi memiliki fungsi untuk mengubah data akun.
Jika endpoint tersebut hanya memeriksa apakah session pengguna valid tanpa memastikan bahwa request memang berasal dari konteks yang sah, maka terdapat potensi CSRF.
Inilah inti dari vulnerability tersebut.
6. Tindakan Berhasil Dilakukan
Jika seluruh kondisi yang diperlukan terpenuhi, tindakan yang dipicu attacker dapat dijalankan menggunakan hak akses korban.
Dampaknya bergantung pada fungsi yang rentan.
Contohnya dapat berupa perubahan:
- Informasi profil
- Alamat email
- Pengaturan akun
- Preferensi tertentu
- Data lainnya
Dalam aplikasi yang memiliki fungsi sensitif dan perlindungan yang lemah, dampaknya dapat menjadi lebih serius.
Contoh Sederhana CSRF Attack
Bayangkan terdapat sebuah website bernama:
contoh-website.com
Pengguna sudah login ke website tersebut.
Website memiliki fungsi untuk mengubah sebuah pengaturan akun.
Pada aplikasi yang rentan, server hanya memeriksa:
"Apakah pengguna memiliki session yang valid?"
Jika jawabannya ya, request diproses.
Masalahnya, server tidak memverifikasi apakah request tersebut benar-benar dibuat melalui tindakan yang diinginkan pengguna.
Kemudian attacker mencoba membuat korban mengunjungi halaman lain yang memicu request ke endpoint tersebut.
Jika browser mengirimkan autentikasi yang relevan dan aplikasi tidak memiliki pertahanan CSRF yang tepat, server dapat memproses request tersebut.
Inilah gambaran sederhana dari Cross-Site Request Forgery.
Apakah CSRF Selalu Bisa Mengubah Password?
Tidak.
Ini merupakan salah satu bagian yang perlu diluruskan.
Contoh perubahan password sering digunakan untuk menjelaskan konsep CSRF, tetapi tidak semua fitur perubahan password otomatis rentan terhadap CSRF.
Banyak aplikasi modern memiliki perlindungan tambahan untuk tindakan sensitif.
Misalnya:
- Meminta password lama
- Meminta OTP
- Meminta MFA
- Memerlukan CSRF token
- Memerlukan re-authentication
Karena itu, jangan menyimpulkan bahwa setiap endpoint perubahan password pasti dapat dieksploitasi menggunakan CSRF.
Yang menentukan adalah bagaimana aplikasi mengimplementasikan autentikasi, authorization, request validation, dan perlindungan CSRF.
Mengapa CSRF Berbahaya?
CSRF dapat berbahaya karena serangan ini memanfaatkan kepercayaan aplikasi terhadap browser yang sudah terautentikasi.
Server biasanya perlu mengetahui:
"Apakah request ini berasal dari user yang memiliki hak akses?"
Namun, autentikasi saja belum tentu menjawab:
"Apakah user benar-benar bermaksud melakukan tindakan ini?"
Dua pertanyaan tersebut berbeda.
Misalnya:
Authentication:
"User ini sudah login."
Intent:
"Apakah user benar-benar ingin melakukan perubahan tersebut?"
CSRF terutama memanfaatkan kesenjangan antara kedua konsep tersebut.
Dampak CSRF Attack
Dampak CSRF sangat bergantung pada fungsi aplikasi yang terkena vulnerability.
Beberapa kemungkinan dampaknya antara lain:
1. Perubahan Data
Attacker dapat mencoba memengaruhi data tertentu pada akun korban.
2. Perubahan Pengaturan
Pengaturan akun tertentu dapat diubah jika endpoint terkait rentan dan tidak memiliki perlindungan yang memadai.
3. Perubahan Informasi Kontak
Jika fungsi tersebut dapat dipanggil tanpa validasi CSRF yang tepat, informasi kontak dapat menjadi target.
4. Transaksi Tidak Diinginkan
Pada aplikasi finansial atau e-commerce, fungsi tertentu yang melakukan perubahan state dapat memiliki risiko lebih tinggi.
Namun, keberhasilan skenario seperti ini sangat bergantung pada desain aplikasi dan kontrol keamanan lainnya.
CSRF vs XSS: Apa Bedanya?
Pemula sering mencampurkan CSRF dan XSS karena keduanya sama-sama berkaitan dengan aplikasi web.
Padahal, keduanya berbeda.
CSRF
CSRF mencoba membuat browser korban mengirimkan request yang tidak diinginkan ke aplikasi target.
Fokusnya adalah pada tindakan yang dilakukan menggunakan konteks autentikasi korban.
XSS
Cross-Site Scripting (XSS) terjadi ketika attacker dapat memasukkan atau menjalankan script yang kemudian dieksekusi dalam konteks browser korban.
XSS dapat digunakan untuk berbagai tujuan, termasuk manipulasi halaman atau melakukan tindakan tertentu sebagai korban.
Secara sederhana:
CSRF → memanfaatkan request dan konteks autentikasi korban
XSS → mengeksploitasi eksekusi script dalam konteks aplikasi
Keduanya berbeda, tetapi pada kondisi tertentu dapat saling berkaitan dalam sebuah attack chain.
Apakah CSRF Bisa Terjadi Tanpa Cookie?
CSRF paling sering dibahas dalam konteks autentikasi berbasis cookie karena browser dapat mengelola cookie secara otomatis.
Namun, konsep dasarnya lebih luas.
Yang penting adalah apakah terdapat credential atau mekanisme autentikasi yang secara otomatis ikut dalam request, sehingga server menganggap request berasal dari pengguna yang terautentikasi.
Karena itu, jangan menganggap:
"Kalau tidak menggunakan cookie, berarti pasti tidak ada CSRF."
Desain autentikasi aplikasi harus tetap dianalisis secara menyeluruh.
Apa Itu CSRF Token?
Salah satu mekanisme pertahanan yang umum digunakan adalah CSRF Token.
CSRF token adalah nilai unik yang digunakan aplikasi untuk memastikan bahwa request berasal dari konteks aplikasi yang sah.
Secara sederhana:
User membuka form → Server memberikan CSRF token → User mengirim form → Server memeriksa token
Attacker yang berada di situs lain seharusnya tidak dapat memperoleh token tersebut secara sembarangan karena adanya batasan keamanan browser dan desain aplikasi.
Jika token tidak sesuai atau tidak ada, server dapat menolak request.
Contoh Konsep CSRF Token
Misalnya aplikasi memiliki form:
Ubah Pengaturan Akun
Server memberikan token:
csrf_token = RANDOM_VALUE
Ketika user mengirim form, token tersebut ikut dikirim.
Server kemudian memeriksa:
Token yang dikirim = Token yang diharapkan?
Jika benar:
Request → Diproses
Jika salah:
Request → Ditolak
Mekanisme ini membantu server membedakan request yang memiliki konteks valid dari request yang dipalsukan.
Apa Itu SameSite Cookie?
Selain CSRF token, mekanisme keamanan cookie juga memiliki peran penting.
Salah satunya adalah atribut SameSite.
SameSite membantu mengontrol kapan browser mengirimkan cookie dalam konteks cross-site.
Secara umum terdapat beberapa mode:
-
Strict -
Lax -
None
Pengaturan yang tepat dapat membantu mengurangi risiko CSRF.
Namun, developer tetap harus memahami perilaku browser dan kebutuhan aplikasinya.
SameSite bukan alasan untuk mengabaikan desain CSRF protection secara keseluruhan.
Untuk aplikasi yang memiliki tindakan sensitif, pertahanan sebaiknya dirancang secara menyeluruh.
Validasi Origin dan Referer
Aplikasi juga dapat menggunakan informasi seperti:
-
Origin -
Referer
untuk membantu memeriksa dari mana request berasal.
Jika request sensitif berasal dari konteks yang tidak diharapkan, server dapat menolaknya.
Pendekatan ini dapat menjadi lapisan pertahanan tambahan.
Namun, seperti mekanisme keamanan lainnya, implementasinya perlu dilakukan dengan benar dan mempertimbangkan kompatibilitas aplikasi.
Apakah CORS Bisa Mencegah CSRF?
Ini juga merupakan kesalahpahaman yang cukup umum.
CORS dan CSRF adalah mekanisme yang berbeda.
CORS mengatur apakah browser mengizinkan sebuah origin membaca response dari origin lain melalui mekanisme tertentu.
CSRF berhubungan dengan kemampuan attacker memengaruhi browser untuk mengirim request yang memiliki efek pada aplikasi target.
Karena itu:
Mengaktifkan CORS bukan berarti aplikasi otomatis terlindungi dari CSRF.
Developer perlu memahami fungsi masing-masing mekanisme keamanan.
Cara Mencegah CSRF Attack
Untuk melindungi aplikasi dari CSRF, developer dapat menerapkan beberapa lapisan pertahanan.
1. Gunakan CSRF Token
Gunakan token yang tidak dapat ditebak dan validasi token pada request yang relevan.
Token harus diperiksa di sisi server.
2. Gunakan SameSite Cookie
Konfigurasikan cookie session menggunakan atribut SameSite yang sesuai dengan kebutuhan aplikasi.
Ini dapat membantu membatasi pengiriman cookie dalam konteks cross-site.
3. Validasi Origin atau Referer
Untuk operasi sensitif, aplikasi dapat melakukan validasi terhadap origin atau referer sesuai desain keamanan yang digunakan.
4. Gunakan HTTPS
HTTPS melindungi komunikasi antara browser dan server dari berbagai risiko penyadapan atau manipulasi jaringan.
Namun, HTTPS bukan pengganti CSRF protection.
Website yang menggunakan HTTPS tetap dapat memiliki vulnerability CSRF jika implementasi aplikasinya tidak aman.
5. Terapkan Re-authentication untuk Tindakan Sensitif
Untuk aktivitas berisiko tinggi, aplikasi dapat meminta pengguna melakukan autentikasi ulang.
Misalnya:
- Mengubah password
- Mengubah email utama
- Mengubah metode pembayaran
- Melakukan tindakan administratif
Lapisan tambahan ini dapat mengurangi risiko dampak dari serangan tertentu.
Jangan Menggunakan GET untuk Mengubah Data
Salah satu prinsip penting dalam desain aplikasi web adalah GET sebaiknya digunakan untuk mengambil data, bukan melakukan perubahan state yang sensitif.
Contoh yang buruk secara desain:
GET /change-email?...
Lebih tepat menggunakan metode yang sesuai untuk operasi perubahan state, seperti POST, PUT, atau PATCH, tergantung desain API.
Namun, perlu dipahami bahwa:
Mengganti GET menjadi POST saja tidak otomatis menyelesaikan CSRF.
POST juga dapat menjadi target CSRF.
Karena itu, tetap diperlukan mekanisme perlindungan yang tepat.
Bagaimana Developer Menguji CSRF?
Dalam proses security testing, developer atau security tester perlu memeriksa endpoint yang melakukan perubahan state.
Beberapa pertanyaan yang dapat digunakan:
- Apakah endpoint mengubah data?
- Apakah endpoint membutuhkan autentikasi?
- Apakah credential dikirim secara otomatis?
- Apakah terdapat CSRF token?
- Apakah token divalidasi di server?
- Bagaimana konfigurasi SameSite cookie?
- Apakah Origin atau Referer diperiksa?
- Apakah terdapat re-authentication?
- Apakah endpoint dapat dipanggil dari konteks cross-site?
Pengujian harus dilakukan pada sistem yang dimiliki atau telah memberikan izin pengujian.
CSRF pada Aplikasi Modern
Perkembangan teknologi web membuat pola autentikasi semakin beragam.
Aplikasi modern dapat menggunakan:
- Session cookie
- JWT
- OAuth
- OpenID Connect
- API token
- Single Sign-On
- Multi-Factor Authentication
Karena itu, cara menganalisis risiko CSRF juga tidak bisa hanya mengandalkan satu aturan.
Developer perlu memahami:
Bagaimana credential disimpan?
Bagaimana credential dikirim?
Apakah browser mengirimkannya secara otomatis?
Bagaimana server memvalidasi request?
Pertanyaan tersebut jauh lebih penting daripada sekadar menghafal definisi CSRF.
Kesalahan Umum Saat Memahami CSRF
Ada beberapa miskonsepsi yang sering ditemukan.
"CSRF adalah cara mencuri password."
Tidak tepat.
CSRF terutama berhubungan dengan memengaruhi browser korban untuk melakukan request yang tidak diinginkan menggunakan konteks autentikasi yang tersedia.
"HTTPS otomatis mencegah CSRF."
Tidak.
HTTPS melindungi komunikasi, tetapi bukan pengganti CSRF protection.
"POST pasti aman dari CSRF."
Tidak.
POST juga dapat menjadi target CSRF.
"Kalau attacker tidak tahu password, akun pasti aman."
Tidak selalu.
Serangan dapat mengeksploitasi mekanisme autentikasi yang sudah aktif di browser.
"CORS menyelesaikan CSRF."
Tidak.
CORS dan CSRF merupakan konsep keamanan yang berbeda.
Bagaimana Cara Mengingat CSRF?
Jika kamu masih pemula, gunakan analogi sederhana.
Bayangkan kamu sudah masuk ke sebuah kantor.
Kamu memiliki kartu akses yang valid.
Kemudian seseorang membuat kamu melakukan sebuah permintaan ke bagian administrasi tanpa kamu menyadari apa yang sebenarnya terjadi.
Petugas melihat kartu aksesmu dan menganggap permintaan tersebut berasal dari orang yang memiliki izin.
Dalam analogi sederhana tersebut:
Kartu akses = autentikasi
Permintaan = request
Orang yang memengaruhi tindakan = attacker
Permintaan yang tidak kamu sadari = CSRF
Tentu saja analogi ini tidak menggambarkan seluruh detail teknis CSRF, tetapi cukup membantu memahami konsep dasarnya.
CSRF dalam Perspektif Cyber Security
Memahami CSRF sangat penting bagi siapa saja yang ingin mempelajari Web Application Security atau Penetration Testing.
Saat mempelajari CSRF, sebenarnya kita sedang mempelajari konsep yang lebih luas:
Bagaimana browser, user, dan server saling mempercayai satu sama lain.
Kita juga belajar bahwa autentikasi tidak selalu berarti sebuah request benar-benar diinginkan oleh pengguna.
Inilah salah satu alasan mengapa keamanan aplikasi web membutuhkan lebih dari sekadar password.
Developer perlu memperhatikan:
- Authentication
- Authorization
- Session management
- Input validation
- Request validation
- CSRF protection
- Cookie security
- Access control
Semua komponen tersebut saling berhubungan.
Checklist Sederhana Mencegah CSRF
Jika kamu seorang developer, gunakan checklist berikut:
- Gunakan CSRF token pada request yang relevan.
- Validasi token di server.
-
Konfigurasikan cookie dengan
SameSiteyang sesuai. - Gunakan HTTPS.
- Validasi Origin/Referer sesuai kebutuhan.
- Jangan menggunakan GET untuk operasi yang mengubah state.
- Terapkan re-authentication untuk tindakan sangat sensitif.
- Gunakan authentication dan authorization yang tepat.
- Lakukan security testing secara berkala.
- Jangan mengandalkan satu mekanisme keamanan saja.
Kesimpulan
CSRF Attack atau Cross-Site Request Forgery adalah salah satu vulnerability penting dalam keamanan aplikasi web.
Serangan ini bekerja dengan memanfaatkan konteks autentikasi korban untuk memengaruhi browser agar mengirimkan request yang sebenarnya tidak diinginkan oleh korban.
Hal yang membuat CSRF menarik adalah attacker tidak selalu perlu mengetahui password korban.
Jika aplikasi memiliki mekanisme autentikasi berbasis credential yang dikirim secara otomatis dan tidak memiliki perlindungan CSRF yang memadai, request yang dipicu dari konteks lain berpotensi diproses sebagai request yang sah.
Dampaknya sangat bergantung pada endpoint yang rentan dan hak akses korban. Dalam kondisi tertentu, CSRF dapat menyebabkan perubahan data, perubahan pengaturan akun, hingga tindakan sensitif lainnya.
Karena itu, developer perlu menerapkan defense in depth, seperti:
- CSRF Token
- SameSite Cookie
- Origin/Referer Validation
- HTTPS
- Re-authentication
- Authentication dan Authorization yang tepat
Yang paling penting untuk diingat:
Password yang kuat saja belum cukup untuk menjamin keamanan aplikasi web.
Keamanan sebuah aplikasi juga bergantung pada bagaimana browser, server, session, cookie, dan setiap request dirancang serta divalidasi.
Bagi kamu yang sedang belajar Cyber Security, Web Security, atau Penetration Testing, memahami CSRF Attack merupakan fondasi penting sebelum mempelajari vulnerability web lainnya seperti XSS, SQL Injection, IDOR, SSRF, Authentication Bypass, dan Broken Access Control.
Semakin memahami cara kerja aplikasi dari sisi user, browser, dan server, semakin mudah pula memahami bagaimana sebuah vulnerability dapat muncul dan bagaimana cara mencegahnya.
Keamanan aplikasi bukan hanya tentang membuat sistem bisa digunakan, tetapi juga memastikan setiap tindakan yang dilakukan benar-benar berasal dari pihak yang berwenang.
Posting Komentar