Bayangkan Anda memiliki situs web seperti Twitter yang disederhanakan, yang dihosting di a.com. Pengguna yang sudah masuk dapat memasukkan beberapa teks (tweet) ke dalam formulir yang dikirim ke server sebagai permintaan POST dan diterbitkan ketika mereka menekan tombol kirim. Di server pengguna diidentifikasi oleh cookie yang berisi ID sesi unik mereka, sehingga server Anda tahu siapa yang memposting Tweet.
Bentuknya bisa sesederhana itu:
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
Sekarang bayangkan, orang jahat menyalin dan menempelkan formulir ini ke situs web jahatnya, katakanlah b.com. Formulir masih akan berfungsi. Selama pengguna masuk ke Twitter Anda (yaitu mereka punya cookie sesi yang valid untuk a.com), permintaan POST akan dikirim ke
http://a.com/tweetdan diproses seperti biasa ketika pengguna mengklik tombol kirim.
Sejauh ini ini bukan masalah besar selama pengguna dibuat sadar tentang apa sebenarnya bentuknya, tetapi bagaimana jika penjahat kita mengubah bentuk seperti ini:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
Sekarang, jika salah satu pengguna Anda berakhir di situs web orang jahat dan klik "Klik untuk menang!" tombol, formulir dikirimkan ke situs web Anda, pengguna diidentifikasi dengan benar oleh ID sesi dalam cookie dan Tweet tersembunyi dipublikasikan.
Jika penjahat kita bahkan lebih buruk, dia akan membuat pengguna yang tidak bersalah mengirimkan formulir ini segera setelah mereka membuka halaman webnya menggunakan JavaScript, bahkan mungkin benar-benar disembunyikan dalam iframe yang tidak terlihat. Ini pada dasarnya adalah pemalsuan permintaan lintas situs.
Formulir dapat dengan mudah dikirimkan dari mana saja ke mana saja. Secara umum itu adalah fitur yang umum, tetapi ada banyak lagi kasus di mana penting untuk hanya mengizinkan formulir dikirimkan dari domain yang menjadi miliknya.
Lebih buruk lagi jika aplikasi web Anda tidak membedakan antara permintaan POST dan GET (mis. Dalam PHP dengan menggunakan $ _REQUEST alih-alih $ _POST). Jangan lakukan itu! Permintaan pengubah data dapat diajukan semudah <img src="http://a.com/tweet?tweet=This+is+really+bad">, disematkan di situs web jahat atau bahkan email.
Bagaimana cara memastikan formulir hanya dapat dikirimkan dari situs web saya sendiri? Di sinilah token CSRF masuk. Token CSRF adalah string acak yang sulit ditebak. Pada halaman dengan formulir yang ingin Anda lindungi, server akan menghasilkan string acak, token CSRF, menambahkannya ke formulir sebagai bidang tersembunyi dan juga mengingatnya entah bagaimana, baik dengan menyimpannya di sesi atau dengan mengatur cookie mengandung nilai. Sekarang bentuknya akan terlihat seperti ini:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
Ketika pengguna mengirimkan formulir, server hanya perlu membandingkan nilai dari bidang yang diposting csrf-token (nama tidak masalah) dengan token CSRF yang diingat oleh server. Jika kedua string sama, server dapat melanjutkan untuk memproses formulir. Kalau tidak, server harus segera berhenti memproses formulir dan merespons dengan kesalahan.
Mengapa ini bekerja? Ada beberapa alasan mengapa orang jahat dari contoh kami di atas tidak dapat memperoleh token CSRF:
Menyalin kode sumber statis dari halaman kami ke situs web yang berbeda tidak akan berguna, karena nilai bidang tersembunyi berubah dengan setiap pengguna. Tanpa situs web orang jahat itu mengetahui token CSRF pengguna saat ini server Anda akan selalu menolak permintaan POST.
Karena halaman jahat orang jahat dimuat oleh browser pengguna Anda dari domain yang berbeda (b.com, bukan a.com), penjahat tidak memiliki kesempatan untuk kode JavaScript, yang memuat konten dan karenanya CSRF pengguna kami saat ini diambil dari situs Anda. Itu karena browser web tidak mengizinkan permintaan AJAX lintas domain secara default.
Orang jahat juga tidak dapat mengakses cookie yang ditetapkan oleh server Anda, karena domain tidak akan cocok.
Kapan saya harus melindungi terhadap pemalsuan permintaan lintas situs? Jika Anda dapat memastikan bahwa Anda tidak mencampuradukkan GET, POST, dan metode permintaan lainnya seperti yang dijelaskan di atas, langkah awal yang baik adalah melindungi semua permintaan POST secara default.
Anda tidak harus melindungi permintaan PUT dan DELETE, karena seperti yang dijelaskan di atas, formulir HTML standar tidak dapat dikirimkan oleh browser menggunakan metode tersebut.
Sebaliknya, JavaScript memang dapat membuat jenis permintaan lain, mis. Menggunakan fungsi $ .ajax () jQuery, tetapi ingat, agar permintaan AJAX berfungsi, domain harus cocok (selama Anda tidak mengonfigurasi server web Anda secara eksplisit jika tidak) .
Ini berarti, seringkali Anda bahkan tidak perlu menambahkan token CSRF ke permintaan AJAX, bahkan jika itu adalah permintaan POST, tetapi Anda harus memastikan bahwa Anda hanya memintas pemeriksaan CSRF di aplikasi web Anda jika permintaan POST sebenarnya adalah Permintaan AJAX. Anda dapat melakukannya dengan mencari keberadaan header seperti X-Requested-With, yang biasanya diminta oleh AJAX. Anda juga dapat mengatur tajuk khusus lain dan memeriksa keberadaannya di sisi server. Itu aman, karena peramban tidak akan menambahkan header khusus ke pengiriman formulir HTML biasa (lihat di atas), jadi tidak ada kesempatan bagi Tuan Orang Jahat untuk mensimulasikan perilaku ini dengan formulir.
Jika Anda ragu tentang permintaan AJAX, karena karena alasan tertentu Anda tidak dapat memeriksa header seperti X-Requested-With, cukup kirimkan token CSRF yang dihasilkan ke JavaScript Anda dan tambahkan token ke permintaan AJAX. Ada beberapa cara untuk melakukan ini; baik menambahkannya ke payload seperti bentuk HTML biasa, atau menambahkan header khusus ke permintaan AJAX. Selama server Anda tahu di mana mencarinya dalam permintaan masuk dan dapat membandingkannya dengan nilai asli yang diingatnya dari sesi atau cookie, Anda disortir.