Pengantar

Keamanan aplikasi web tidak hanya bergantung pada password dan sistem autentikasi. Setelah pengguna berhasil login, aplikasi juga harus memastikan bahwa setiap tindakan yang dilakukan benar-benar berasal dari pengguna yang sah.

Salah satu ancaman yang memanfaatkan kelemahan tersebut adalah Cross-Site Request Forgery (CSRF).

CSRF merupakan serangan yang membuat browser pengguna mengirimkan request ke aplikasi web yang sedang dipercaya. Karena browser dapat secara otomatis menyertakan cookie sesi pada request tertentu, server dapat menganggap request tersebut berasal dari pengguna yang telah terautentikasi.

Akibatnya, penyerang dapat mencoba membuat korban melakukan tindakan yang tidak diinginkan, seperti mengubah data akun, mengganti alamat email, melakukan transaksi, atau mengubah konfigurasi tertentu.

Menurut OWASP, CSRF terjadi ketika situs berbahaya membuat browser pengguna yang sudah terautentikasi melakukan tindakan yang tidak diinginkan pada aplikasi target (dikutip dari: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html).

Apa Itu Cross-Site Request Forgery?

Pengertian CSRF

Cross-Site Request Forgery, atau sering disebut CSRF/XSRF, adalah jenis serangan yang mengeksploitasi kepercayaan aplikasi terhadap browser pengguna yang sudah terautentikasi.

Berbeda dengan pencurian password secara langsung, penyerang tidak selalu perlu mengetahui password korban.

Sebaliknya, penyerang mencoba memanfaatkan sesi login yang sudah aktif di browser korban.

Contohnya, seorang pengguna sedang login ke sebuah aplikasi perbankan. Pada saat yang sama, pengguna mengunjungi situs lain yang telah disiapkan oleh penyerang.

Situs tersebut kemudian mencoba membuat browser korban mengirimkan request ke aplikasi perbankan.

Jika aplikasi tidak memiliki perlindungan CSRF yang memadai, server dapat menganggap request tersebut sebagai tindakan yang sah dari pengguna.

baca juga : Kernel Samepage Merging (KSM): Cara Linux Menghemat Memori dengan Berbagi Halaman yang Identik

Mengapa CSRF Bisa Terjadi?

Browser Mengirimkan Credential Secara Otomatis

Salah satu faktor utama CSRF adalah mekanisme autentikasi berbasis cookie.

Ketika pengguna berhasil login, server biasanya memberikan session cookie kepada browser.

Contohnya:

Set-Cookie: session_id=abc123

Pada request berikutnya ke domain yang sesuai, browser dapat mengirimkan cookie tersebut secara otomatis.

Masalahnya, server mungkin hanya memeriksa apakah cookie sesi valid tanpa memverifikasi apakah request benar-benar dibuat dari halaman aplikasi yang sah.

Dengan kata lain:

Cookie valid
      ↓
Server menganggap pengguna sah
      ↓
Request dijalankan

Padahal request tersebut dapat dipicu oleh halaman yang dikendalikan penyerang.

Bagaimana Cara Kerja Serangan CSRF?

1. Korban Login ke Aplikasi

Pengguna terlebih dahulu login ke sebuah aplikasi web.

Misalnya:

https://bank.example

Browser kemudian menyimpan session cookie.

2. Korban Mengunjungi Situs Berbahaya

Pengguna membuka situs lain, misalnya:

https://attacker.example

Situs tersebut tidak harus mengetahui password korban.

3. Situs Menyebabkan Request ke Target

Halaman berbahaya mencoba membuat browser melakukan request ke aplikasi target.

Secara konsep:

Attacker Website
       ↓
Browser Korban
       ↓
Target Website

4. Browser Mengirimkan Credential

Jika kebijakan cookie mengizinkannya, browser dapat menyertakan credential yang relevan pada request.

5. Server Memproses Request

Jika aplikasi tidak memiliki validasi tambahan, server dapat menganggap request tersebut sebagai tindakan yang dilakukan pengguna.

Inilah inti dari CSRF.

Contoh Skenario CSRF

Bayangkan sebuah aplikasi memiliki endpoint:

POST /account/change-email

Request yang sah mungkin terlihat seperti:

POST /account/change-email
Cookie: session=USER_SESSION

email=user@example.com

Aplikasi hanya memeriksa apakah session cookie valid.

Jika tidak ada CSRF protection, penyerang dapat mencoba membuat browser korban mengirimkan request serupa.

Jika server menerima request hanya berdasarkan session cookie, tindakan tersebut dapat berhasil tanpa persetujuan eksplisit pengguna.

Apa Dampak CSRF?

Dampak CSRF bergantung pada hak akses korban dan fungsi aplikasi yang rentan.

Perubahan Data Akun

Penyerang dapat mencoba mengubah informasi akun, seperti alamat email atau pengaturan tertentu.

Perubahan Password

Jika endpoint perubahan password tidak memiliki perlindungan yang memadai, CSRF dapat menjadi sangat berbahaya.

Transaksi Finansial

Pada aplikasi finansial, CSRF dapat berpotensi menyebabkan transaksi yang tidak diinginkan.

Perubahan Konfigurasi

Akun administrator yang menjadi korban dapat menyebabkan perubahan konfigurasi penting pada aplikasi.

Pengambilalihan Akun

Dalam skenario tertentu, rangkaian serangan CSRF dapat berkontribusi terhadap account takeover, terutama jika terdapat endpoint sensitif yang dapat dimanipulasi.

OWASP mencatat bahwa dampak CSRF bergantung pada hak akses korban; tindakan yang dapat dilakukan dapat mencakup perubahan password, transfer dana, pembelian, hingga perubahan hak akses (dikutip dari: https://owasp.org/www-community/attacks/csrf).

baca juga : LLMNR & NBT-NS Poisoning: Ancaman Name Resolution yang Sering Terabaikan di Jaringan Windows

CSRF Token sebagai Perlindungan Utama

Apa Itu CSRF Token?

Salah satu metode paling umum untuk mencegah CSRF adalah menggunakan CSRF token.

Token merupakan nilai acak dan sulit ditebak yang dibuat oleh server.

Contohnya:

<input type="hidden"
       name="csrf_token"
       value="random-token-value">

Ketika pengguna mengirimkan form, token tersebut ikut dikirimkan ke server.

Server kemudian memverifikasi token sebelum menjalankan tindakan.

Cara Kerja CSRF Token

Alur sederhananya:

Server
  ↓
Membuat CSRF Token
  ↓
Halaman dikirim ke Browser
  ↓
User mengirim Form
  ↓
CSRF Token ikut dikirim
  ↓
Server melakukan validasi
  ↓
Valid → Request diproses
Invalid → Request ditolak

Penyerang biasanya tidak dapat mengetahui token yang valid jika token dibuat secara acak dan tidak dapat diakses dari origin yang tidak dipercaya.

Karena itu, request palsu yang tidak memiliki token valid dapat ditolak.

Synchronizer Token Pattern

Salah satu pendekatan CSRF protection adalah Synchronizer Token Pattern.

Pada metode ini, server menyimpan token yang terkait dengan sesi pengguna.

Setiap request yang mengubah state aplikasi harus menyertakan token tersebut.

Server kemudian membandingkan token yang diterima dengan token yang tersimpan.

Jika tidak cocok, request ditolak.

Metode ini sangat umum digunakan pada aplikasi yang menggunakan session-based authentication.

Double Submit Cookie

Metode lain adalah Double Submit Cookie.

Dalam pendekatan ini, server memberikan token melalui cookie dan aplikasi juga mengharuskan token yang sama dikirimkan melalui parameter request atau header.

Contohnya:

Cookie: csrf_token=abcxyz
X-CSRF-Token: abcxyz

Server kemudian membandingkan keduanya.

Pendekatan ini dapat digunakan pada aplikasi tertentu yang membutuhkan mekanisme stateless, tetapi implementasinya harus dilakukan dengan hati-hati.

SameSite Cookie

Apa Itu SameSite?

Cookie memiliki atribut bernama SameSite yang dapat membatasi kapan cookie dikirim dalam konteks cross-site.

Terdapat tiga nilai utama:

SameSite=Strict
SameSite=Lax
SameSite=None

Strict memberikan pembatasan paling ketat.

Lax memberikan pembatasan yang lebih longgar dan menjadi pilihan umum untuk berbagai kebutuhan web.

None memungkinkan cookie dikirim dalam konteks cross-site, tetapi membutuhkan atribut Secure.

MDN menjelaskan bahwa atribut SameSite dapat memberikan perlindungan terhadap CSRF dengan mengontrol apakah cookie dikirim dalam request cross-site, meskipun sebaiknya digunakan sebagai defense-in-depth dan bukan satu-satunya mekanisme perlindungan (dikutip dari: https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF).

CSRF Token vs SameSite

Keduanya memiliki fungsi yang berbeda.

Mekanisme Fungsi
CSRF Token Memastikan request memiliki token rahasia yang valid
SameSite Cookie Membatasi pengiriman cookie dalam konteks cross-site
Origin Validation Memeriksa asal request
Fetch Metadata Membantu menentukan konteks request

Dalam aplikasi sensitif, penggunaan beberapa lapisan perlindungan dapat memberikan pertahanan yang lebih kuat.

Mengapa GET Tidak Boleh Mengubah Data?

Salah satu prinsip penting dalam keamanan aplikasi web adalah HTTP GET seharusnya tidak digunakan untuk melakukan perubahan state.

Contoh yang buruk:

GET /delete-account

Jika endpoint seperti ini dapat menghapus akun, serangan CSRF menjadi lebih mudah dilakukan.

Sebaliknya, operasi yang mengubah state sebaiknya menggunakan metode seperti:

POST
PUT
PATCH
DELETE

Tetapi penggunaan metode tersebut saja tidak otomatis mencegah CSRF.

Token atau mekanisme perlindungan lainnya tetap diperlukan jika model autentikasinya memungkinkan serangan CSRF.

Validasi Origin dan Referer

Origin Header

Server dapat memeriksa header Origin untuk memastikan request berasal dari origin yang diharapkan.

Contohnya:

Origin: https://example.com

Server dapat menolak request jika origin tidak sesuai dengan daftar yang diperbolehkan.

Referer Header

Referer juga dapat digunakan sebagai sinyal tambahan.

Namun, header ini tidak sebaiknya menjadi satu-satunya mekanisme keamanan karena berbagai faktor dapat memengaruhi keberadaannya dan nilainya.

Fetch Metadata

Browser modern menyediakan sejumlah header Fetch Metadata seperti:

Sec-Fetch-Site
Sec-Fetch-Mode
Sec-Fetch-Dest

Informasi tersebut dapat membantu server memahami konteks sebuah request.

Misalnya, server dapat mendeteksi apakah request berasal dari:

same-origin
same-site
cross-site

Pendekatan ini dapat digunakan sebagai lapisan tambahan untuk memblokir request cross-site yang mencurigakan.

CSRF pada REST API

Tidak semua API memiliki risiko CSRF yang sama.

Jika API menggunakan session cookie sebagai autentikasi, CSRF tetap menjadi perhatian.

Sebaliknya, pola autentikasi tertentu yang menggunakan token secara eksplisit pada header dapat mengubah karakteristik ancaman.

Contohnya:

Authorization: Bearer <token>

Browser tidak secara otomatis menambahkan header Authorization: Bearer seperti browser menambahkan cookie.

Namun, keamanan API tetap bergantung pada bagaimana token tersebut disimpan dan digunakan.

CSRF dan CORS

CORS (Cross-Origin Resource Sharing) bukan mekanisme khusus untuk mencegah CSRF.

CORS mengatur apakah browser mengizinkan JavaScript dari origin tertentu membaca response dari origin lain.

Sementara CSRF berfokus pada pencegahan request tidak sah yang menyebabkan perubahan state.

Konfigurasi CORS yang salah, terutama ketika credential diizinkan untuk origin yang tidak tepat, dapat memperbesar risiko keamanan.

Karena itu, CORS dan CSRF harus dipahami sebagai dua mekanisme keamanan yang berbeda.

CSRF vs XSS

CSRF dan Cross-Site Scripting (XSS) sering dianggap serupa karena keduanya dapat melibatkan browser korban.

Namun, keduanya memiliki konsep berbeda.

Aspek CSRF XSS
Target Request aplikasi Kode di browser
Penyebab Validasi request lemah Input/output tidak diamankan
Fokus Memaksa tindakan Menjalankan script
Contoh Dampak Perubahan akun Pencurian data/session
Mitigasi CSRF Token, SameSite Output Encoding, CSP

Keduanya juga dapat saling berkaitan.

Aplikasi yang memiliki XSS dapat kehilangan efektivitas sebagian mekanisme CSRF karena script yang berjalan dalam origin aplikasi dapat mengakses konteks yang seharusnya hanya tersedia bagi aplikasi tersebut.

Cara Mencegah CSRF pada Aplikasi Web

Gunakan CSRF Protection dari Framework

Banyak framework modern sudah menyediakan mekanisme CSRF protection.

Jika framework yang digunakan memiliki fitur tersebut, gunakan mekanisme resmi daripada membuat implementasi sendiri tanpa kebutuhan khusus.

Gunakan CSRF Token

Semua request yang mengubah state dan menggunakan autentikasi berbasis cookie sebaiknya memiliki perlindungan CSRF yang sesuai.

Atur SameSite Cookie

Gunakan:

SameSite=Strict

jika kebutuhan aplikasi memungkinkan.

Jika Strict menyebabkan masalah kompatibilitas atau navigasi, Lax dapat menjadi pilihan yang lebih fleksibel.

Jangan Gunakan GET untuk Perubahan State

GET sebaiknya hanya digunakan untuk operasi yang tidak mengubah data.

Validasi Origin

Untuk endpoint sensitif, validasi Origin dapat digunakan sebagai lapisan tambahan.

Gunakan HTTPS

HTTPS tidak secara langsung mencegah CSRF, tetapi tetap merupakan fondasi penting untuk menjaga kerahasiaan dan integritas komunikasi antara browser dan server.

Checklist Keamanan CSRF

Administrator dan developer dapat menggunakan checklist berikut:

  • Gunakan CSRF token.
  • Validasi token pada server.
  • Gunakan proteksi CSRF bawaan framework.
  • Atur cookie dengan SameSite.
  • Gunakan Secure untuk cookie melalui HTTPS.
  • Gunakan HttpOnly untuk session cookie jika sesuai.
  • Jangan gunakan GET untuk perubahan state.
  • Validasi Origin untuk endpoint sensitif.
  • Pertimbangkan Fetch Metadata.
  • Audit konfigurasi CORS.
  • Lakukan pengujian keamanan secara berkala.
  • Perbaiki XSS karena XSS dapat melemahkan mekanisme CSRF.

baca juga : Windows Registry Forensics: Mengungkap Jejak Digital Tersembunyi di Balik Sistem Windows

Kesimpulan

Cross-Site Request Forgery (CSRF) merupakan serangan yang memanfaatkan kepercayaan aplikasi terhadap browser pengguna yang telah terautentikasi. Penyerang berusaha membuat browser korban mengirimkan request yang tidak diinginkan ke aplikasi target.

Risiko CSRF menjadi lebih besar pada aplikasi yang menggunakan cookie sebagai mekanisme autentikasi dan tidak memiliki validasi tambahan terhadap request yang mengubah data.

Perlindungan utama dapat dilakukan menggunakan CSRF token, sementara SameSite cookie, validasi Origin, Fetch Metadata, dan konfigurasi keamanan lainnya dapat digunakan sebagai lapisan pertahanan tambahan.

Developer juga harus memastikan bahwa endpoint yang mengubah state tidak menggunakan HTTP GET dan bahwa konfigurasi CORS tidak memberikan akses cross-origin secara berlebihan.

Pada akhirnya, pencegahan CSRF bukan hanya tentang menambahkan satu token. Keamanan yang baik membutuhkan kombinasi antara mekanisme autentikasi yang tepat, validasi request di sisi server, konfigurasi cookie yang aman, dan pengujian aplikasi secara berkala.

Related Posts: