Saya percaya akan sulit untuk menemukan jawaban yang pasti untuk pertanyaan ini mengapa token CSRF "diperlukan" di Magento's add to cart GET action. Saya akan berusaha menafsirkan tujuannya. Saya bukan ahli keamanan dan ini adalah interpretasi saya terhadap CSRF dalam konteks khusus ini.
Konteks
Dari owasp.org
Pemalsuan Permintaan Lintas Situs (CSRF) adalah serangan yang memaksa pengguna akhir untuk melakukan tindakan yang tidak diinginkan pada aplikasi web di mana mereka saat ini diautentikasi. Serangan CSRF secara khusus menargetkan permintaan yang diubah negara, bukan pencurian data, karena penyerang tidak memiliki cara untuk melihat respons terhadap permintaan yang dipalsukan.
Salah satu contoh serangan ini adalah menyematkan gambar tersembunyi di email atau halaman web alternatif:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Server web tidak akan membedakan dari mana permintaan itu berasal dan dengan setia akan menambahkan item ke keranjang pengguna itu.
Tujuan mencegah serangan CSRF adalah untuk mencegah permintaan yang berubah negara . Menambahkan item ke troli akan dianggap sebagai perubahan status. Secara umum, saya akan mempertimbangkan ini adalah perubahan keadaan tidak berbahaya dibandingkan dengan mengirimkan pesanan, mentransfer dana atau memperbarui alamat email.
Mengenai perubahan status dan metode HTTP, RFC 2616 mengatakan yang berikut:
Secara khusus, konvensi telah ditetapkan bahwa metode GET dan HEAD TIDAK HARUS memiliki signifikansi untuk mengambil tindakan selain pengambilan. Metode-metode ini harus dianggap "aman".
Magento dan CSRF
Magento menerapkan mekanisme pencegahan CSRF untuk admin dan area frontend dengan menggunakan token (form key). Saya berasumsi bahwa tujuan Magento, sebagai platform yang dimaksudkan untuk dibangun oleh pengembang lain, adalah untuk mengamankan semua permintaan yang diubah oleh negara. Alasannya adalah bahwa mereka tidak tahu apa yang mungkin diungkapkan oleh pengembang pelaksana atau ekstensi pihak ketiga. Lebih aman untuk mengamankan semua permintaan perubahan negara daripada memiliki sesuatu yang diekspos oleh modul pihak ke-3 dan menjadi PR buruk untuk platform. Saya sebenarnya tidak tahu apakah semua permintaan perubahan negara diamankan dari serangan CSRF.
Satu hal yang perlu diperhatikan adalah bahwa Magento tidak selalu menggunakan kunci formulir untuk melindungi permintaan perubahan negara. Misalnya, permintaan Hapus Dari Keranjang ( /checkout/cart/delete/id/{ID}) dan Hapus Alamat Pelanggan ( /customer/address/delete/id/{ID}) keduanya adalah MENDAPATKAN permintaan yang lulus dalam ID Entitas. Pengontrol (atau model) kemudian menangani memastikan bahwa pengguna berwenang untuk menghapus catatan entitas tersebut (mengubah keadaan). Ini adalah dua contoh di mana Magento tidak mengikuti RFC 2616 . Agar adil, untuk beberapa kasus penggunaan mungkin tidak praktis atau perlu dilakukan.
Tampaknya pemeriksaan formulir kunci dalam Mage_Checkout_CartController::addActionmetode telah ditambahkan di versi 1.8. Dari catatan rilis kami memiliki yang berikut untuk dimatikan:
Mengatasi masalah yang bisa mengakibatkan Pemalsuan Permintaan Lintas Situs (CSRF) di toko web.
Sayangnya bahasanya tidak jelas dan "bisa saja" membuat saya percaya itu karena asumsi yang saya sebutkan sebelumnya: permintaan perubahan keadaan yang aman. Mungkin ada kemungkinan mengirim parameter tambahan yang menyebabkan semacam perilaku yang tidak diinginkan:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
Idenya adalah bahwa dengan menambahkan sesuatu ke keranjang ada beberapa kode (inti atau pihak ke-3) yang kebetulan dipicu saat menambahkan ke keranjang, misalnya melalui beberapa acara yang dikirim.
Tampaknya tidak mungkin bahwa kerentanan semacam itu ada di luar kotak dan jika memang ada yang berharap Magento akan melakukan pekerjaan yang lebih baik untuk mengungkapkan rincian / risiko. Satu risiko yang bisa saya lihat adalah bahwa Magento secara buta menyimpan parameter permintaan selama menambahkan ke keranjang di product_optionskolom tabel item pesanan penjualan (lihat info_buyRequest:). Secara teori seseorang dapat mengelabui sekelompok pengguna untuk menambahkan item ke keranjang mereka dengan parameter kueri aneh dan itu akan disimpan ke dalam sales_flat_quote_item_optiontabel dan akhirnya sales_flat_order_itemtabel jika mereka juga bisa membuat para pengguna untuk mengkonversi. Ini tampaknya sangat tidak mungkin bagi saya dalam banyak kasus.
Tambahkan ke Masalah Kunci Formulir Keranjang
Salah satu masalah besar yang dihadapi orang dengan implementasi FPC dan token CSRF adalah mereka akhirnya di-cache. Klien pertama yang menghangatkan cache menghasilkan token, ketika klien kedua mendapatkan cache HIT mereka sekarang telah diberi halaman dengan token pengguna pertama. Saat mengirimkan formulir, token tidak akan cocok.
Magento Enterprise menggunakan placeholder untuk menemukan / mengganti kunci formulir di halaman yang di-cache. Implementasi pernis akan menyukai menggunakan ESI ke mana pun kunci formulir digunakan.
Saya ingin tahu apakah ekstensi "ajax cart" yang lebih populer akhirnya memeriksa token CSRF selama penambahan permintaan ke keranjang.
Satu permintaan fitur di mana saya akhirnya melepaskan token CSRF untuk tindakan add to cart memungkinkan kemampuan membuat tautan add to cart untuk digunakan dalam email atau situs web lainnya (media sosial). Terkadang pemasaran ingin agar pengguna langsung menambahkan item ke troli dan mengarahkan ulang ke troli atau checkout segera. Ini tidak dapat dengan mudah dilakukan jika token CSRF diperlukan. Saya hanya akan merekomendasikan ini jika Anda merasa nyaman dengan tingkat risiko dan percaya pada kode Anda sendiri dan pihak ketiga mana pun.