it-swarm-id.com

Haruskah saya menggunakan AntiForgeryToken dalam segala bentuk, bahkan masuk dan mendaftar?

Saya menjalankan situs yang agak besar dengan ribuan kunjungan setiap hari, dan basis pengguna yang agak besar. Sejak saya mulai bermigrasi ke MVC 3, saya telah meletakkan AntiForgeryToken dalam sejumlah bentuk, yang mengubah data yang dilindungi dll.

Beberapa bentuk lain, seperti login dan registrasi juga menggunakan AntiForgeryToken sekarang, tetapi saya menjadi ragu tentang kebutuhan mereka di sana, karena beberapa alasan ...

Formulir login membutuhkan poster untuk mengetahui kredensial yang benar. Saya benar-benar tidak bisa memikirkan cara apa pun serangan CSRF akan mendapat manfaat di sini, terutama jika saya memeriksa bahwa permintaan datang dari Host yang sama (memeriksa header Referer).

Token AntiForgeryToken menghasilkan nilai yang berbeda setiap kali halaman dimuat. Jika saya memiliki dua tab terbuka dengan halaman login, dan kemudian mencoba mempostingnya, yang pertama akan berhasil dimuat. Yang kedua akan gagal dengan AntiForgeryTokenException (pertama memuat kedua halaman, lalu coba mempostingnya). Dengan halaman yang lebih aman - ini jelas merupakan kejahatan yang diperlukan, dengan halaman login - sepertinya berlebihan, dan hanya meminta masalah.

Mungkin ada alasan lain mengapa seseorang harus menggunakan atau tidak menggunakan token dalam bentuk yang. Apakah saya benar dengan berasumsi bahwa menggunakan token di setiap formulir postingan adalah berlebihan, dan jika demikian - bentuk apa yang akan mendapat manfaat darinya, dan yang mana yang pasti bukan manfaat?

P.S. Pertanyaan ini juga ditanyakan pada StackOverflow, tapi saya tidak sepenuhnya yakin. Saya pikir saya akan bertanya di sini, untuk lebih banyak keamanan cakupan

82
Artiom Chilaru

Ya, penting untuk memasukkan token anti-pemalsuan untuk halaman login.

Mengapa? Karena potensi serangan "login CSRF". Dalam serangan CSRF login, penyerang mencatat korban ke situs target dengan akun penyerang. Pertimbangkan, misalnya, serangan terhadap Alice, yang merupakan pengguna Paypal, oleh penyerang jahat Evelyn. Jika Paypal tidak melindungi halaman loginnya dari serangan CSRF (mis., Dengan token anti-pemalsuan), maka penyerang dapat secara diam-diam login browser Alice ke akun Evelyn di Paypal. Alice dibawa ke situs web Paypal, dan Alice login, tetapi login sebagai Evelyn. Misalkan Alice kemudian mengklik pada halaman untuk menautkan kartu kreditnya ke akun Paypal-nya, dan memasukkan nomor kartu kreditnya. Alice berpikir dia menautkan kartu kreditnya ke akun Paypal-nya, tetapi sebenarnya dia telah menautkannya ke akun Evelyn. Sekarang Evelyn dapat membeli barang-barang, dan memilikinya dibebankan ke kartu kredit Alice. Ups. Ini halus dan agak tidak jelas, tetapi cukup serius sehingga Anda harus menyertakan token anti-pemalsuan untuk target aksi formulir yang digunakan untuk masuk. Lihat makalah ini untuk detail lebih lanjut dan beberapa contoh dunia nyata seperti kerentanan.

Kapan OK untuk meninggalkan token anti-pemalsuan? Secara umum, jika targetnya adalah URL, dan mengakses URL itu tidak memiliki efek samping, maka Anda tidak perlu memasukkan token anti-pemalsuan dalam URL itu.

Aturan praktisnya adalah: sertakan token anti-pemalsuan dalam semua permintaan POST, tetapi Anda tidak memerlukannya untuk permintaan GET. Namun, aturan praktis yang kasar ini adalah perkiraan yang sangat kasar Ini membuat asumsi bahwa permintaan GET semua akan bebas efek samping. Dalam aplikasi web yang dirancang dengan baik, semoga seperti itu terjadi, tetapi dalam praktiknya, kadang-kadang desainer aplikasi web tidak mengikuti pedoman itu dan menerapkan penangan GET. yang memiliki efek samping (ini adalah ide yang buruk, tetapi itu tidak biasa). Itulah sebabnya saya menyarankan pedoman berdasarkan apakah permintaan akan memiliki efek samping pada keadaan aplikasi web atau tidak, alih-alih berdasarkan pada GET vs POS.

72
D.W.

Di mana mungkin perlu untuk memiliki token pada halaman login adalah ketika Anda perlu mencegah seseorang dari jahat masuk Anda ke situs dengan kredensial tertentu. Saya bisa melihat ini menjadi kasusnya jika seseorang dibingkai untuk sesuatu yang mengharuskan masuk dengan pengguna partikel. Dengan itu dikatakan, itu sedikit contoh buat.

2
Steve