---
# System prepended metadata

title: Cross-site request forgery (_**CSRF**_)

---

---
title: Cross-site request forgery (_**CSRF**_)
author: Linuz Tri Erianto
date: 2020
---

# Cross-site request forgery (_**CSRF**_)

Cross-site request forgery (_**CSRF**_) adalah sebuah serangan yang dipaksakan oleh pengguna agar backend mengeksekusi perintah yang tidak seharusnya diizinkan. Seperti tadi, kita mencoba login (dari mana saja).

![_**CSRF**_-Attack](https://portswigger.net/web-security/images/cross-site%20request%20forgery.svg)

## Bagaimana _**CSRF**_ Bekerja?
_**CSRF**_ attack bisa terjadi, dengan 3 kondisi seperti ini:
- **Tindakan yang relavan.** Ada tindakan dalam aplikasi yang penyerang punya alasan untuk melakukan. Ini mungkin tindakan khusus (seperti memodifikasi izin untuk pengguna lain) atau tindakan apa pun pada data khusus pengguna (seperti mengubah kata sandi pengguna sendiri).
- **Penanganan sesi berbasis cookie.** Melakukan tindakan melibatkan mengeluarkan satu atau lebih permintaan HTTP, dan aplikasi hanya mengandalkan cookie sesi untuk mengidentifikasi pengguna yang telah membuat permintaan. Tidak ada mekanisme lain untuk sesi pelacakan atau memvalidasi permintaan pengguna.
- **Tidak ada parameter permintaan yang tidak dapat diprediksi**. Permintaan yang melakukan tindakan tidak mengandung parameter apa pun yang nilainya tidak dapat ditentukan atau ditebak penyerang. Misalnya, ketika menyebabkan pengguna mengubah kata sandi mereka, fungsinya tidak rentan jika penyerang perlu mengetahui nilai kata sandi yang ada.

Misalnya, anggap sebuah aplikasi berisi fungsi yang memungkinkan pengguna mengubah alamat email pada akun mereka. Saat pengguna melakukan tindakan ini, mereka membuat permintaan HTTP seperti berikut:
```
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com
```

Ini memenuhi persyaratan yang diperlukan untuk _**CSRF**_:

- Tindakan mengubah alamat email pada akun pengguna menarik bagi penyerang. Setelah tindakan ini, penyerang biasanya dapat memicu pengaturan ulang kata sandi dan mengambil kendali penuh dari akun pengguna.
- Aplikasi menggunakan cookie sesi untuk mengidentifikasi pengguna mana yang mengeluarkan permintaan. Tidak ada token atau mekanisme lain di tempat untuk melacak sesi pengguna.
- Penyerang dapat dengan mudah menentukan nilai-nilai parameter permintaan yang diperlukan untuk melakukan tindakan.

## Bagaimana Untuk Menghindari _**CSRF**_?
Untuk menghindari _**CSRF**_, kita bisa menggunakan _**CSRF Token**_. 
Token CSRF adalah nilai unik, rahasia, dan tak terduga yang dihasilkan oleh aplikasi sisi server dan ditransmisikan ke klien sedemikian rupa sehingga dimasukkan dalam permintaan HTTP berikutnya yang dibuat oleh klien. Ketika permintaan nanti dibuat, aplikasi sisi server memvalidasi bahwa permintaan menyertakan token yang diharapkan dan menolak permintaan jika token hilang atau tidak valid.
Contoh :
```
<input type="hidden" name="csrf-token" value="CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz" />
```
Token CSRF dapat mencegah serangan CSRF dengan membuatnya tidak mungkin bagi penyerang untuk membuat permintaan HTTP yang sepenuhnya valid yang cocok untuk memberi makan kepada pengguna korban. Karena penyerang tidak dapat menentukan atau memprediksi nilai token CSRF pengguna, mereka tidak dapat membuat permintaan dengan semua parameter yang diperlukan untuk aplikasi untuk memenuhi permintaan tersebut.

## Bagaimana Token CSRF harus divalidasi?
Ketika token CSRF dibuat, itu harus disimpan di sisi server dalam data sesi pengguna. Ketika permintaan berikutnya diterima yang memerlukan validasi, aplikasi sisi server harus memverifikasi bahwa permintaan menyertakan token yang cocok dengan nilai yang disimpan dalam sesi pengguna. Validasi ini harus dilakukan terlepas dari metode HTTP atau jenis konten permintaan. Jika permintaan tidak mengandung token sama sekali, itu harus ditolak dengan cara yang sama seperti ketika token yang tidak valid hadir.