Kasus penggunaan pertahanan CSRF
Anda memiliki perangkat tertanam yang mendukung UI web berbasis HTTP melalui alamat ip pribadi.
Apakah masuk akal untuk mengimplementasikan pertahanan CSRF melalui HTTP (bukan HTTPS)?
Jawaban
Jika permintaan HTTP mampu mengubah status, mungkin diperlukan perlindungan CSRF. Apakah permintaan dienkripsi atau tidak pada lapisan transport memiliki sedikit atau tidak ada hubungannya dengan ini.
Tanpa perlindungan CSRF, penyerang yang meyakinkan Anda untuk mengunjungi situs web mereka atau bahkan satu sumber daya mungkin dapat mengirim permintaan ke perangkat tertanam Anda dan mengambil kendali atasnya, jika browser korban diotorisasi dengan benar atau ada otentikasi yang tidak memadai atau rusak. Ini terjadi terlepas dari apakah HTTP atau HTTPS digunakan.
Ya, idealnya semuanya melalui HTTPS. Namun, opsi "terbaik" untuk sebagian besar vendor saat ini adalah mengirimkan perangkat tersemat dengan sertifikat yang ditandatangani sendiri yang, selain baik untuk penggunaan pertama yang terpercaya dan menggagalkan sniffing pasif, tidak jauh lebih baik daripada HTTP biasa di banyak skenario. Seringkali, pengguna masih akan mendapatkan peringatan sertifikat dan mengkliknya. Hingga masalah ini diatasi, prospek HTTPS pada perangkat yang disematkan masih suram.
(Mengatasi editan Anda yang sekarang dihapus) Memang, XSS mengabaikan mitigasi CSRF. Namun, model ancaman tampaknya sedikit berbeda di sini, karena cara itu lebih kecil kemungkinannya bagi musuh untuk dapat mengeksploitasi XSS di perangkat Anda yang disematkan daripada masalah CSRF, karena mereka harus masuk ke perangkat pada kasus pertama.
Tanpa pertahanan CSRF, penyerang dapat memalsukan email (mungkin dengan alamat palsu yang ditargetkan dengan baik) dengan peringatan pemantauan, memberi tahu Anda untuk memeriksa karena ada masalah kritis. Di dalam email, mungkin ada tautan ke http: // yourswitch / factory_reset.
Vektor serangan dapat bervariasi.
Kecuali jika Anda kebetulan menggunakan FQDN atau alamat IP default (katakanlah, 192.168.1.1 di mana-mana) untuk perangkat itu, jenis serangan khusus ini akan cukup ditargetkan. Penyerang harus membuat permintaan ke sakelar yang benar-benar melakukan sesuatu yang "menarik" (ini membutuhkan mengetahui FQDN / IP dan vendor / model untuk mendapatkan jalur yang berguna) dan mengirimkan tautan ini kepada Anda dengan cara yang tidak menimbulkan terlalu banyak alis Anda (email dari Internet mungkin aneh. Mungkin sesuatu yang memalsukan email pemantauan tanpa balasan yang Anda gunakan?).
Seperti biasa, yang penting adalah memahami model ancaman dan biaya vs manfaat tindakan balasan Anda.
Iya.
Dalam kasus switch jaringan atau router, serangan tipikal yang mungkin diderita adalah konfigurasi ulang perangkat (seperti meneruskan port internal ke luar), mengubah DNS yang diberikannya ke yang jahat, dll. Tindakan ini harus memerlukan otentikasi, tetapi Anda harus memperhitungkan bahwa itu bisa menggunakan kata sandi default yang tidak berubah juga.
(dan ya, hal semacam ini memang terjadi di alam liar)
Fakta bahwa itu didasarkan pada alamat pribadi http://192.168.1.1tidak memberikan perlindungan, karena serangan akan dilakukan oleh halaman web jahat, mengirimkan melalui browser pengguna di dalam jaringan permintaan jahat yang -diterima karena kurangnya perlindungan CSRF- akan salah mengkonfigurasi switch.
Mozilla Firefox telah membuka bug 354493 selama 14 tahun, yang akan menghindari serangan dari alamat non-RFC-1918 ke RFC 1918, tetapi sejauh ini belum diimplementasikan.