Terlepas dari kenyataan bahwa dalam daftar kerentanan OWASP Top 10 2017 serangan CSRF terakhir dipublikasikan diklasifikasikan sebagai "Dihapus, tetapi tidak dilupakan", kami memutuskan bahwa tidak akan berlebihan untuk mengingat kembali bagaimana mempertahankan serangan CSRF, dengan mengandalkan pada aturan yang sama yang disediakan oleh OWASP.
Menggunakan Token CSRFMenggunakan token (metode stateless dan statefull) adalah metode perlindungan utama dan paling populer. Token harus unik untuk setiap sesi pengguna, yang dihasilkan oleh generator nomor acak semu yang kriptografisnya kuat. OWASP juga merekomendasikan penggunaan algoritma AES256-GCM dan SHA256 / 512 untuk enkripsi saat menggunakan HMAC.
Ada beberapa pendekatan untuk bekerja dengan token: Sinkronisasi Token, Pola Token berbasis Enkripsi, Token Berbasis HMAC
Sinkronisasi tokenMenggunakan pendekatan Synchronizer Token (metode statefull), itu berarti mengirim token pada setiap permintaan, menyiratkan beberapa perubahan di sisi server. Jika token tidak valid, maka server menolak permintaan tersebut.
Saat mengirim permintaan ke server, disarankan untuk menambahkan token ke parameter permintaan daripada ke header. Jika Anda tetap memasukkan token di header permintaan, maka pastikan itu tidak dicatat di server. Token yang diterima dapat disimpan
di sisi klien dalam bidang tersembunyi:<form action="/post.php" method="post"> <input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ"> ... </form>
di header: POST /page HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Content-Type: application/json Host: example.com X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ
atau dalam cookie POST /page HTTP/1.1 Host: example.com Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ; Content-Type: application/x-www-form-urlencoded
OWASP merekomendasikan menyimpan token di header, menjelaskan bahwa bahkan jika token dibuka atau kedaluwarsa, penyerang masih tidak dapat memalsukan permintaan, karena browser.
Juga, untuk meningkatkan tingkat keamanan metode yang diusulkan, diusulkan untuk membuat nama parameter token acak dan / atau token itu sendiri untuk setiap permintaan. Dengan pendekatan ini, waktu di mana penyerang dapat menggunakan token yang dicuri menjadi minimal. Namun, ini dapat menyebabkan masalah kegunaan. Misalnya, mengklik tombol "Kembali" dapat mengakibatkan pengiriman token yang tidak valid ke server, yang terdapat pada halaman sebelumnya.
Mengirim token menggunakan permintaan GET tidak dianjurkan, karena dengan pendekatan ini token dapat diungkapkan: dalam riwayat browser, file log, header pengarah.
Token berbasis enkripsiPendekatan ini tidak memiliki kewarganegaraan, karena menggunakan enkripsi / dekripsi untuk memvalidasi token, dan oleh karena itu tidak memerlukan penyimpanan token di sisi server.
Server menghasilkan token yang terdiri dari pengidentifikasi sesi dan cap waktu (untuk mencegah serangan replay). Untuk enkripsi, disarankan untuk menggunakan algoritma enkripsi AES256 dalam mode enkripsi blok GSM / GSM-SIV. Menggunakan mode ECB sangat tidak dianjurkan. Token yang dienkripsi oleh server dikembalikan ke klien dengan cara yang sama seperti dalam kasus “Sinkronisasi Token” di bidang formulir tersembunyi atau di tajuk / parameter respons. Setelah menerima token, server harus mendekripsi, kemudian memverifikasi pengidentifikasi sesi, dan juga memeriksa cap waktu dengan waktu saat ini dan memastikan bahwa itu tidak melebihi token yang ditetapkan seumur hidup.
Jika verifikasi pengidentifikasi sesi berhasil, tetapi peta waktu tidak, maka permintaan dapat dianggap valid. Dalam semua kasus lain, disarankan untuk menolak permintaan dan mendaftarkannya untuk lebih memahami bagaimana menanggapi permintaan tersebut.
Token Berbasis HMAC
Ini juga tidak memerlukan penyimpanan token, prinsip operasi mirip dengan Token berbasis Enkripsi, kecuali bahwa alih-alih mengenkripsi token, fungsi HMAC (kode otentikasi pesan berbasis hash) digunakan untuk menghasilkan token (disarankan untuk menggunakan SHA256 atau algoritma yang lebih kuat). Dalam kasus ini, token adalah hasil dari fungsi HMAC dari pengidentifikasi sesi pengguna + cap waktu.
Otomatisasi TokenMasalah utama dalam menangkal serangan CSRF adalah bahwa pengembang sering lupa menambahkan fungsionalitas untuk bekerja dengan token. Untuk menghindari masalah seperti itu, ada baiknya mengotomatisasi proses ini:
• menulis pembungkus yang secara otomatis menambahkan token ke permintaan melalui tag formulir atau saat menggunakan ajax. Misalnya, Spring Security mengambil pendekatan yang sama setiap kali tag <form: form> digunakan.
• menulis kail yang memotong lalu lintas dan menambahkan token ke semua sumber daya yang rentan. Karena sangat sulit untuk menganalisis permintaan mana yang dilakukan perubahan keadaan, memerlukan token, disarankan untuk memasukkan token dalam semua respons POST, tetapi perlu mempertimbangkan biaya kinerja
• secara otomatis menambahkan token saat merender halaman. Pendekatan ini digunakan oleh Penjaga CSRF: token ditambahkan ke semua atribut href dan src, bidang tersembunyi dan dalam semua bentuk
Sebelum mencoba menulis sistem pembuatan token otomatis Anda sendiri, disarankan untuk menjelaskan apakah kerangka kerja yang Anda gunakan memiliki kemampuan untuk memberikan perlindungan terhadap serangan CSRF secara default. Misalnya, kerangka kerja Django yang sama menerapkan perlindungan terhadap CSRF.
Login CSRFMenggunakan CSRF dalam formulir login, penyerang dapat masuk,
menyamar sebagai korban. Kerentanan seperti itu dihadapi oleh raksasa seperti PayPal dan Google.
Anda dapat menangani CSRF dalam formulir login dengan membuat pra-sesi yang dibuat sebelum pengguna diautentikasi, dan dengan memasukkan token dalam formulir login.
Cookie SamesiteSameSite Cookie adalah atribut yang dijelaskan dalam RFC6265bis yang bertujuan untuk menangkal serangan CSRF. Ini berfungsi sebagai berikut. Salah satu metode perlindungan adalah memeriksa header sumber dan referensi, yang dengannya Anda dapat memahami dari mana permintaan itu berasal, tetapi pendekatan ini membutuhkan penerapan mekanisme verifikasi. Menggunakan atribut SameSite, kami membatasi pengiriman cookie dengan permintaan dari sumber daya asing. Atribut ini memiliki beberapa nilai yang mungkin: Strict, Lax, dan None.
Menggunakan nilai ketat berarti bahwa browser tidak akan mengirim cookie dari sumber apa pun yang tidak cocok dengan nama domain sumber daya saat ini.
Kelemahan nilai memungkinkan untuk tidak memblokir cookie dari sumber daya eksternal, transisi yang dilakukan dengan cara yang aman - menggunakan protokol HTTPS. Lax menemukan keseimbangan antara kegunaan dan keamanan.
Mengatur atribut sangat sederhana:
Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax
Pada saat penulisan, dukungan untuk atribut oleh browser terlihat seperti ini:
Penting untuk diingat bahwa atribut ini harus digunakan sebagai ukuran perlindungan tambahan, dan bukan sebagai cara untuk melakukannya tanpa menggunakan token CSRF.
Memeriksa HeaderSeperti disebutkan di atas, salah satu metode perlindungan adalah memeriksa nilai pengarah dan asal dari header permintaan.
Inti dari pemeriksaan ini adalah untuk memeriksa nilai header di sisi server. Jika mereka cocok dengan sumber daya, maka permintaan dianggap benar, jika tidak maka ditolak. Jika header Asal tidak ada, Anda perlu memastikan bahwa nilai Pengarah cocok dengan sumber daya saat ini. OWASP merekomendasikan penolakan permintaan yang tidak mengandung header Origin atau Referrer. Anda juga dapat mencatat semua permintaan seperti itu untuk menganalisisnya nanti dan memutuskan bagaimana cara menanganinya.
Namun, segala sesuatunya menjadi rumit jika aplikasi Anda berada di belakang server proxy, karena URL di header akan berbeda. Dalam hal ini, ada beberapa opsi:
• Konfigurasikan aplikasi Anda sehingga Anda selalu tahu asal usul permintaan. Masalah dengan pendekatan ini adalah menetapkan nilai yang tepat jika aplikasi Anda digunakan di beberapa lingkungan (misalnya, dev, QA, produksi), yang mengarah ke masalah dukungan
• gunakan tajuk Host. Header ini akan memungkinkan Anda untuk menentukan sumber permintaan terlepas dari lingkungan
• menggunakan header X-Forwarded-Host, yang tujuannya adalah untuk menyimpan header asli yang diterima oleh server proxy
Semua metode yang dijelaskan hanya berfungsi bila ada header asal dan referensi. Tetapi ada beberapa kasus ketika tajuk ini hilang. Berikut adalah beberapa kasus di mana tajuk ini tidak termasuk dalam permintaan:
• IE 11 tidak termasuk header Asal untuk situs tepercaya. Tetap hanya mengandalkan header Referer.
• dalam kasus pengalihan, Asal tidak termasuk dalam permintaan, karena diyakini bahwa itu mungkin berisi informasi rahasia yang tidak boleh dikirim ke sumber lain
• Header asal diaktifkan untuk semua permintaan lintas situs, tetapi sebagian besar browser menambahkannya hanya untuk permintaan POST / DELETE / PUT
Sebagai aturan, sejumlah kecil lalu lintas masuk ke dalam kategori yang dijelaskan, tetapi seringkali Anda tidak ingin kehilangan bahkan sebagian kecil dari pengguna ini, oleh karena itu dianggap sah untuk meminta dengan nilai nol untuk asal / pengarah atau dengan nilai yang sesuai dengan daftar domain tepercaya.
Kirim Cookie Ganda
Pendekatan ini cukup sederhana untuk diimplementasikan dan tidak memerlukan penyimpanan token di sisi server (stateless). Inti dari metode ini adalah mengirim token dalam parameter permintaan dan cookie oleh pengguna. Setiap permintaan yang memerlukan perubahan status, kami memverifikasi nilai token dalam cookie dan dalam permintaan. Jika verifikasi pengidentifikasi sesi berhasil, tetapi peta waktu tidak, maka permintaan dapat dianggap valid