กรณีการใช้งานการป้องกัน CSRF
คุณมีอุปกรณ์ฝังตัวที่รองรับ UI เว็บที่ใช้ HTTP ผ่านที่อยู่ IP ส่วนตัว
การใช้การป้องกัน CSRF ผ่าน HTTP (ไม่ใช่ HTTPS) เหมาะสมหรือไม่
คำตอบ
หากคำขอ HTTP สามารถเปลี่ยนสถานะได้อาจต้องมีการป้องกัน CSRF ไม่ว่าคำขอจะเข้ารหัสที่เลเยอร์การขนส่งนั้นมีความสัมพันธ์กับสิ่งนี้เพียงเล็กน้อยหรือไม่
หากไม่มีการป้องกัน CSRF ผู้โจมตีที่ชักจูงให้คุณเยี่ยมชมเว็บไซต์ของตนหรือแม้แต่แหล่งข้อมูลเดียวอาจสามารถส่งคำขอไปยังอุปกรณ์ฝังตัวของคุณและเข้าควบคุมได้หากเบราว์เซอร์ของเหยื่อได้รับอนุญาตอย่างถูกต้องหรือมีการตรวจสอบสิทธิ์ไม่เพียงพอหรือใช้งานไม่ได้ สิ่งนี้เกิดขึ้นไม่ว่าจะใช้ HTTP หรือ HTTPS
ใช่ทุกอย่างจะผ่าน HTTPS อย่างไรก็ตามตัวเลือกที่ "ดีที่สุด" สำหรับผู้ขายส่วนใหญ่ในตอนนี้คือการจัดส่งอุปกรณ์ฝังตัวที่มีใบรับรองที่ลงนามด้วยตนเองซึ่งนอกจากจะเหมาะสำหรับการใช้งานครั้งแรกและการป้องกันการดมกลิ่นแบบพาสซีฟแล้วยังไม่ดีไปกว่า HTTP ธรรมดาในหลาย ๆ สถานการณ์ บ่อยครั้งผู้ใช้จะยังคงได้รับคำเตือนเกี่ยวกับใบรับรองและคลิกผ่าน จนกว่าปัญหานี้จะได้รับการแก้ไขแนวโน้มของ HTTPS บนอุปกรณ์ฝังตัวยังคงเป็นเรื่องที่น่าสลด
(จัดการกับการแก้ไขที่คุณลบไปแล้ว) อันที่จริง XSS ข้ามการบรรเทา CSRF อย่างไรก็ตามรูปแบบภัยคุกคามดูเหมือนจะแตกต่างกันเล็กน้อยที่นี่เนื่องจากมีโอกาสน้อยที่ฝ่ายตรงข้ามจะสามารถใช้ประโยชน์จาก XSS ในอุปกรณ์ฝังตัวของคุณได้มากกว่าปัญหา CSRF เนื่องจากพวกเขาจะต้องเข้าสู่อุปกรณ์ในกรณีแรก
หากไม่มีการป้องกัน CSRF ผู้โจมตีอาจปลอมแปลงอีเมล (อาจใช้ที่อยู่ปลอมที่กำหนดเป้าหมายอย่างเหมาะสม) พร้อมกับการแจ้งเตือนการตรวจสอบโดยแจ้งให้คุณตรวจสอบเนื่องจากมีปัญหาร้ายแรง ภายในอีเมลอาจมีลิงก์ไปยัง http: // yourswitch / factory_reset
เวกเตอร์การโจมตีอาจแตกต่างกันไป
หากคุณไม่ได้ใช้ FQDN หรือที่อยู่ IP เริ่มต้น (เช่น 192.168.1.1 ที่แพร่หลาย) สำหรับอุปกรณ์นั้นการโจมตีประเภทนี้จะเป็นเป้าหมายที่ค่อนข้างชัดเจน ผู้โจมตีจะต้องสร้างคำขอไปยังสวิตช์ซึ่งทำสิ่งที่ "น่าสนใจ" ได้จริง (ซึ่งต้องรู้ FQDN / IP และผู้ขาย / รุ่นเพื่อให้ได้เส้นทางที่เป็นประโยชน์) และส่งลิงก์นี้ให้คุณในลักษณะที่ไม่เพิ่มมากเกินไป คิ้วของคุณ (อีเมลจากอินเทอร์เน็ตน่าจะแปลกอาจมีบางอย่างปลอมอีเมลตรวจสอบที่ไม่ตอบกลับที่คุณใช้)
ตามปกติแล้วการทำความเข้าใจรูปแบบภัยคุกคามและต้นทุนเทียบกับผลประโยชน์ของมาตรการตอบโต้ของคุณ
ใช่.
ในกรณีของสวิตช์เครือข่ายหรือเราเตอร์การโจมตีโดยทั่วไปที่อาจเกิดขึ้นได้คือการกำหนดค่าอุปกรณ์ใหม่ (เช่นการส่งต่อพอร์ตภายในไปยังภายนอก) การเปลี่ยน DNS ที่มีให้กับผู้ประสงค์ร้ายเป็นต้นการดำเนินการเหล่านี้ควรต้องมี การรับรองความถูกต้อง แต่คุณควรคำนึงถึงว่าอาจใช้รหัสผ่านเริ่มต้นที่ไม่เปลี่ยนแปลงด้วย
(และใช่สิ่งนี้เกิดขึ้นในป่า)
ความจริงที่ว่ามันขึ้นอยู่กับที่อยู่ส่วนตัว http://192.168.1.1ไม่ให้การป้องกันเนื่องจากการโจมตีจะเกิดขึ้นจากหน้าเว็บที่เป็นอันตรายการส่งคำขอที่เป็นอันตรายผ่านเบราว์เซอร์ของผู้ใช้ภายในเครือข่ายซึ่งได้รับการยอมรับเนื่องจากไม่มีการป้องกัน CSRF จะกำหนดค่าสวิตช์ไม่ถูกต้อง
Mozilla Firefox มีจุดบกพร่อง 354493 ที่เปิดมาเป็นเวลา 14 ปีซึ่งจะหลีกเลี่ยงการโจมตีจากที่อยู่ที่ไม่ใช่ RFC-1918 ไปยัง RFC 1918 แต่จนถึงขณะนี้ยังไม่มีการใช้งาน