Apa itu CSRF? Pengertian CSRF dan Implemntasi di Form input Website

Sigit N
Artikel
Apa itu CSRF? Pengertian CSRF dan Implemntasi di Form input Website
Konten Halaman

CSRF Token adalah value yang unik, rahasia, dan tidak terduga sehingga dihasilkan oleh aplikasi di bagian sisi server kemudian dikirimkan ke klien dalam permintaan HTTP berikutnya yang nantinya dibuat di sisi klien.

Apa itu CSRF Token ?

Cross-Site Request Forgery (CSRF) adalah salah satu serangan tertua dan paling sederhana di Web, namun masih efektif di banyak situs web dan dapat menyebabkan konsekuensi yang parah, seperti kerugian ekonomi dan pengambilalihan akun. Sayangnya, alat dan teknik yang diusulkan sejauh ini untuk mengidentifikasi kerentanan CSRF membutuhkan peninjauan manual oleh manusia atau mengasumsikan ketersediaan kode sumber aplikasi web.

Saat permintaan selanjutnya dibuat, aplikasi di bagian sisi server melakukan validasi permintaan tersebut yang diharapkan dan akan menolak permintaan jika CSRF token tidak ada atau tidak valid.

CSRF Token dapat mencegah serangan CSRF yang akan membuat penyerang tidak mungkin melakukan permintaan HTTP yang secara sepenuhnya valid yang cocok untuk diumpankan ke pengguna korban. Dikarena penyerang tidak dapat menentukan atau memprediksi nilai token CSRF pengguna, sehingga tidak dapat membuat permintaan dengan semua parameter yang diperlukan aplikasi untuk memenuhi permintaan tersebut.

Bagaimana CSRF Token dihasilkan?

Token CSRF harus berisi entropi yang signifikan dan sangat tidak terduga, dengan properti yang sama seperti token sesi pada umumnya. anda harus menggunakan kekuatan kriptografi pseudo-random number generator (PRNG), yang diunggulkan dengan stempel waktu saat dibuat plus rahasia statis.

Jika anda memerlukan jaminan lebih lanjut di luar kekuatan PRNG, anda dapat menghasilkan token individual dengan menggabungkan outputnya dengan beberapa entropi khusus pengguna dan mengambil hash yang kuat dari seluruh struktur.

Bagaimana token CSRF diimplementasikan dalam Form?

CSRF Token bersifat rahasia dan ditangani dengan cara yang aman sepanjang life cycle program. Biasanya tindakan yang efektif adalah mengirimkan token ke klien secara tersembunyi pada bagian Form HTML yang dikirimkan menggunakan metode POST. Token kemudian akan sisipkan sebagai parameter permintaan saat Form HTML dikirimkan, seperti contoh berikut:

<input
  type="hidden"
  name="csrf-token"
  value="6W0lfqK7lgawP0A0SfukwRxuX56dATmttapH9N"
/>

Untuk keamanan tambahan, bagian yang berisi token CSRF harus ditempatkan sedini mungkin dalam HTML, idealnya sebelum bagian input dan lokasi mana pun di mana data yang dapat dikontrol pengguna disematkan di dalam HTML.

Sehingga akan mengurangi berbagai teknik di mana penyerang dapat menggunakan data yang dibuat untuk memanipulasi dokumen HTML dan menangkap bagian dari isinya.

Pendekatan alternatif, menempatkan token ke dalam string kueri URL, cukup kurang aman karena:

  • Tercatat di berbagai lokasi di sisi klien dan server.
  • Dapat ditransmisikan ke pihak ketiga di dalam header HTTP Referer.
  • Dapat ditampilkan di layar dalam browser user.

Beberapa aplikasi mengirimkan CSRF token dalam header secara khusus. Maka menjadi sebuah pertahanan lebih lanjut terhadap penyerang yang akan berhasil memprediksi atau menangkap token pengguna lain, karena browser biasanya tidak mengizinkan header custom untuk dikirim lintas domain. Namun, pendekatan tersebut membatasi aplikasi untuk membuat permintaan yang dilindungi CSRF menggunakan XHR (sebagai lawan dari formulir HTML) dan mungkin dianggap terlalu rumit untuk banyak situasi. CSRF Token tidak boleh dikirimkan dalam cookie file.

Bagaimana melakukan validasi CSRF token?

Ketika token CSRF dibuat, harus disimpan di sisi server dalam data season pengguna. Ketika permintaan berikutnya diterima yang memerlukan validasi, aplikasi sisi server harus memverifikasi bahwa permintaan tersebut menyertakan token yang cocok dengan nilai yang disimpan dalam sesi pengguna. Validasi ini harus dilakukan terlepas dari metode HTTP atau tipe konten permintaan. Jika permintaan tidak memiliki token yang sama, permintaan harus ditolak dengan cara sama seperti saat token dalam kondisi tidak valid.

Berikut ini skenario contoh kasus dari CSRF di akun bank untuk bahan pembelajaran:

Penyerang menganalisis situs web selama fase penelitian serangan. Dia akan sering membuat akun di situs korban (atau di aplikasi web korban) dan kemudian menguji berbagai transaksi dengan memperhatikan contoh-contoh penting seperti otentikasi, perubahan kata sandi, transfer dana, dll.

Banyak dari penguji penetrasi yang lebih baru pada awalnya bingung dengan langkah :

  • Bagaimana penyerang mendapatkan akses ? Ini seringkali cukup mudah:
  • Siapa pun dapat membuat akun Amazon, eBay, PayPal, Facebook, dll.,.
  • Atau melakukan pengunduhan dan jalankan program open source (atau membeli sebagian besar perangkat premium). Atau melakukan pembukaan rekening bank dengan menyetor $20. untuk menguji apakah akan dapat mendapatkan pengetahuan secara penuh.

Seringkali dengan menemukan transaksi yang tidak memerlukan elemen dinamis (seperti token transaksi acak yang aman) dan atau menggunakan anti-CSRF yang lemah terhadap perlindungan (seperti hanya memeriksa referer alamat situs).

Selama penelitian, kita anggap penyerang menemukan skrip transfer.php ini, yang tampaknya tidak menggunakan apapun jenis elemen yang dinamis contoh URL:

https://bank.example.com/transfer.php?acct=4242&amount=1000

Penyerang kemudian melakukan transfer berupa uang ke rekeningnya sendiri (terkadang dari satu ke yang lain, seperti memeriksa untuk mendebet). Penyerang juga dapat membuka dua akun, mentransfer dari satu akun ke akun lainnya. Penyerang dengan mengamati secara detail dan hati=hari di setiap proses transaksi (biasanya melalui proxy intersepsi seperti Burp Suite atau ZAP), dengan hati-hati memeriksa apakah ada mekanisme keamanannya.