Apakah formulir masuk perlu bukti terhadap serangan CSRF?

161

Dari apa yang saya pelajari sejauh ini, tujuan token adalah untuk mencegah penyerang memalsukan pengiriman formulir.

Misalnya, jika situs web memiliki formulir yang memasukkan item tambahan ke keranjang belanja Anda, dan penyerang bisa mengirim spam keranjang belanja Anda dengan barang-barang yang tidak Anda inginkan.

Ini masuk akal karena mungkin ada beberapa input yang valid untuk formulir keranjang belanja, yang harus dilakukan penyerang hanyalah mengetahui item yang dijual oleh situs web.

Saya mengerti bagaimana token bekerja dan menambah keamanan dalam kasus ini, karena mereka memastikan pengguna benar-benar mengisi dan menekan tombol "Kirim" dari formulir untuk setiap item yang ditambahkan ke keranjang.

Namun, apakah token menambah keamanan ke formulir login pengguna, yang memerlukan nama pengguna dan kata sandi?

Karena nama pengguna dan kata sandi sangat unik, penyerang harus mengetahui keduanya agar pemalsuan masuk berfungsi (bahkan jika Anda tidak memiliki pengaturan token), dan jika penyerang sudah mengetahui hal itu, ia bisa langsung masuk ke situs web diri. Belum lagi, serangan CSRF yang membuat pengguna masuk sendiri tidak akan memiliki tujuan praktis.

Apakah pemahaman saya tentang serangan dan token CSRF benar? Dan apakah mereka tidak berguna untuk formulir login pengguna seperti yang saya duga?

php token csrf

— php_learner
sumber

Mereka dapat membajak router Anda, karena Anda mungkin menggunakan kata sandi default untuk itu, dan itu tidak dilindungi CSRF untuk login.

— AbiusX

Ya, jadi situs web lain tidak dapat meniru formulir login Anda. Apa yang bisa mereka capai dengan melakukannya? Pertama, Anda tidak ingin itu. Kedua: Kasus kegagalan yang sangat mudah seperti memblokir pengguna karena kata sandi salah dan tidak. Terkadang, bisa dihindari.

— mayankcpdixit

126

Iya. Secara umum, Anda perlu mengamankan formulir login Anda dari serangan CSRF sama seperti yang lain.

Kalau tidak, situs Anda rentan terhadap serangan "phising domain tepercaya". Singkatnya, halaman login CSRF-rentan memungkinkan penyerang untuk berbagi akun pengguna dengan korban.

Kerentanan bermain seperti ini:

Penyerang membuat akun host di domain tepercaya
Penyerang memalsukan permintaan login di browser korban dengan kredensial akun host ini
Penyerang menipu korban untuk menggunakan situs tepercaya, di mana mereka mungkin tidak memperhatikan bahwa mereka masuk melalui akun host
Penyerang sekarang memiliki akses ke data atau metadata apa pun yang korban "buat" (sengaja atau tidak sengaja) saat peramban mereka masuk dengan akun host

Sebagai contoh terkait, pertimbangkan YouTube . YouTube memungkinkan pengguna untuk melihat catatan riwayat tontonan "mereka sendiri", dan formulir masuk mereka rentan terhadap CSRF! Jadi sebagai hasilnya, penyerang bisa membuat account dengan password mereka tahu, login korban ke YouTube menggunakan yang akun - menguntit apa video korban sedang menonton.

Ada beberapa diskusi di utas komentar ini yang menyiratkan bahwa "hanya" dapat digunakan untuk pelanggaran privasi seperti itu. Mungkin, tetapi mengutip bagian dalam artikel CSRF Wikipedia :

Login CSRF memungkinkan berbagai serangan baru; misalnya, penyerang kemudian dapat masuk ke situs dengan kredensial yang sah dan melihat informasi pribadi seperti riwayat aktivitas yang telah disimpan dalam akun.

Penekanan pada "serangan novel". Bayangkan dampak serangan phishing terhadap pengguna Anda, lalu bayangkan kata serangan phishing bekerja melalui bookmark tepercaya milik pengguna ke situs Anda! Makalah yang terhubung dalam utas komentar tersebut memberikan beberapa contoh yang melampaui serangan privasi sederhana.

— natevw
sumber

6

Bagaimana perlindungan CSRF membantu? Adakah yang mencegah penyerang meminta token CSRFnya sendiri dan hanya mengirimkannya? Karena tidak ada sesi terotentikasi, tidak ada alasan bagi server web untuk memilih satu token daripada yang lain.

— A. Wilson

2

"Apakah ada sesuatu yang mencegah penyerang meminta token CSRFnya sendiri dan hanya mengirimkannya?" - Iya! Itulah asumsi di balik logika pencegahan CSRF. Browser memang mengizinkan pengiriman formulir untuk menargetkan asal lain, tetapi mereka tidak pernah [secara sengaja] mengizinkan JS untuk membaca data di seluruh situs, kecuali sekarang melalui opt-in CORS. Kecuali jika Anda salah mengatur CORS, penyerang dapat memicu pengiriman formulir (yang mungkin menyertakan token CSRF yang ada dalam cookie ) tetapi tidak memiliki cara untuk mengetahui token untuk mengirim salinan kedua yang diperlukan (misalnya di badan / header). Jadi kode CSRF akan ditolak.

— natevw

7

Saya pikir komentar terakhir Anda salah (Anda salah mengerti apa yang dikatakan A. Wilson). Kami mengatakan bahwa penyerang dapat memuat http://good.com/login.htmldalam satu klien, mengurai token CSRF bersarang, dan kemudian menerbitkan http://bad.com/login.htmlyang berisi bentuk modifikasi yang mengajukan nya username, password dan Token terlepas dari apa jenis korban dalam. CORS tidak berlaku karena Anda' Saya punya dua klien terpisah: penyerang dan korban. Jadi untuk mengulangi pertanyaan: apakah perlindungan CSRF benar-benar berfungsi untuk formulir masuk?

— Gili

8

Ya, CSRF akan melindungi formulir login dari pemalsuan permintaan lintas situs . Token CSRF yang tepat unik secara kriptografis setiap kali dihasilkan. Tentu, penyerang bisa mendapatkan token sendiri tetapi masih TIDAK MENCOCOK cookie [yang berpotensi tidak disetel] yang dimiliki korban di browser mereka, dan penyerang tidak memiliki cara untuk mengatur cookie tersebut tanpa mengorbankan halaman pada domain yang bagus. (Contoh Anda tampaknya agak membingungkan antara CSRF dan semacam serangan phishing yang aneh, jadi, saya tidak yakin apakah saya menjawab pertanyaan Anda yang sebenarnya ...)

— natevw

3

Saya mungkin salah, tetapi sepertinya ada ancaman signifikan jika pengguna secara tidak sengaja melakukan sesuatu yang berkaitan dengan pembelian barang. Misalnya, penyerang menipu pengguna untuk masuk ke situs web, dan pengguna mulai membeli barang tanpa menyadari bahwa mereka ada di akun lain (pikirkan Amazon atau serupa). Sekarang penyerang memiliki akses ke informasi pembayaran yang disimpan, dapat mengarahkan kembali pembelian, dll.

— you786

14

Pemahaman Anda benar - inti dari CSRF adalah bahwa penyerang dapat memalsukan permintaan yang tampak sah dari sebelumnya. Tetapi ini tidak dapat dilakukan dengan formulir login kecuali penyerang mengetahui nama pengguna dan kata sandi korban, dalam hal ini ada cara yang lebih efisien untuk menyerang (masuk sendiri).

Pada akhirnya satu-satunya hal yang dapat dilakukan penyerang adalah ketidaknyamanan pengguna Anda dengan melakukan spam login gagal, ketika sistem keamanan mungkin mengunci pengguna untuk jangka waktu tertentu.

— Jon
sumber

2

Wow, balas super cepat! Terima kasih banyak! Sekarang saya dapat terus membangun situs web saya dengan percaya diri.

— php_learner

21

Login CSRF masih dapat digunakan untuk serangan terhadap privasi pengguna seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: Makalah yang cukup menarik, terima kasih untuk tautannya. Tetapi itu bergantung pada login pengguna dengan akun di bawah kendali penyerang dan mengasumsikan bahwa pengguna tidak akan menyadari ada sesuatu yang tidak benar dan menganggap bahwa pengguna akan menghasilkan informasi sensitif yang kemudian akan disimpan di server. Jadi IMHO itu kurang serius daripada CSRF "klasik".

— Jon

6

@ Jon Ya, ini bisa menjadi kurang serius, tetapi pada akhirnya bisa lebih dari sekadar ketidaknyamanan, yaitu invasi privasi. Setiap layanan harus menentukan model ancaman mereka sendiri dan menanganinya. Untuk melakukan itu, Anda setidaknya perlu mengetahui kemungkinan ancaman. Itu sebabnya saya menambahkan 2 sen saya.

— squiddle

1

Tolong dapatkah Anda memperluas bagaimana mereka akan "Pada akhirnya satu-satunya hal yang dapat dilakukan penyerang adalah ketidaknyamanan pengguna Anda dengan mengirim spam gagal login, ketika sistem keamanan mungkin mengunci pengguna untuk jangka waktu tertentu."

— samthebest

0

Ya , jadi situs web lain tidak dapat meniru formulir login Anda! Sesimpel itu.

Apa yang bisa mereka capai dengan melakukannya?

Pertama: Anda tidak ingin itu.
Kedua: Bahkan kasus kegagalan yang sangat sederhana seperti:
- memblokir pengguna karena kata sandi salah nno. Terkadang, bisa dihindari.
- Lansiran peretasan flase dapat dicegah. dll.

— mayankcpdixit
sumber

Sebagian besar poin ini salah. Penyerang dapat membuat formulir login, membuat kredensial pengguna memuat formulir login (dengan csrf token) dan memposting tiga bagian informasi ke target. CSRF tidak mencegah hal ini.

— Snapey

@Snapey Browser biasanya tidak mengizinkan JS membaca data CSRF. Menggunakan JS Anda tidak bisa meniru permintaan pengiriman formulir asli.

— mayankcpdixit

Token csrf sering diteruskan ke klien untuk digunakan oleh javascript. Saya tidak berbicara tentang cors, saya mengambil tentang penyerang hanya meminta formulir login dan mengisi kredensial. @mayankcpdxit. Anda tampaknya menyiratkan bahwa csrf mencegah isian kredensial, padahal tidak.

— Snapey

Secara teoritis, ya itu tidak bisa dicegah. Tetapi tidak mungkin untuk mengotomatiskan isian kredensial setelah CSRF jika Anda berhenti memuat formulir CSRF dalam iframe dan berhenti mengizinkan req asal-asal.

— mayankcpdixit

-1

Pra-masuk validasi CSRF tidak masuk akal IMHO.

Terima kasih kepada @squiddle untuk tautannya: seclab.stanford.edu/websec/csrf/csrf.pdf , kita dapat membaca di halaman pertama:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Jika Anda mencoba pra-masuk validasi CSRF, maka Anda memberi peluang penyerang peluang untuk mengikis kode yang valid dari situs web Anda! Dia kemudian dapat memposting ulang token mengalahkan tujuannya.

Mungkin penyerang kemudian dapat mencoba menebak nama pengguna situs Anda. Apa yang saya lakukan, jika alamat IP mencoba menebak katakan 10 nama pengguna tanpa hasil, saya hanya daftar hitam itu.

— Patrice Gagnon
sumber