การป้องกัน CSRF ด้วยส่วนหัว CORS Origin เทียบกับโทเค็น CSRF

คำถามนี้เกี่ยวกับการป้องกันการโจมตีด้วยการปลอมแปลงคำขอข้ามไซต์เท่านั้น

โดยเฉพาะเกี่ยวกับ: การป้องกันผ่านส่วนหัว Origin (CORS) ดีเท่ากับการป้องกันผ่านโทเค็น CSRF หรือไม่?

ตัวอย่าง:

• อลิซเข้าสู่ระบบ (โดยใช้คุกกี้) ด้วยเบราว์เซอร์ของเธอไปที่ " https://example.com " ฉันคิดว่าเธอใช้เบราว์เซอร์ที่ทันสมัย
• อลิซไปที่ " https://evil.com " และโค้ดฝั่งไคลเอ็นต์ของ evil.com ดำเนินการขอ " https://example.com " (สถานการณ์ CSRF แบบคลาสสิก)

ดังนั้น:

• หากเราไม่ตรวจสอบส่วนหัว Origin (ฝั่งเซิร์ฟเวอร์) และไม่มีโทเค็น CSRF เรามีช่องโหว่ด้านความปลอดภัย CSRF
• หากเราตรวจสอบโทเค็น CSRF แสดงว่าเราปลอดภัย (แต่น่าเบื่อเล็กน้อย)
• หากเราตรวจสอบส่วนหัว Origin คำขอจากโค้ดฝั่งไคลเอ็นต์ของ evil.com ควรถูกบล็อกเช่นเดียวกับที่ทำเมื่อใช้โทเค็น CSRF - ยกเว้นหากเป็นไปได้ที่โค้ดของ evil.com จะตั้งค่าส่วนหัว Origin

ฉันรู้ว่าสิ่งนี้ไม่ควรเป็นไปได้กับ XHR (ดูเช่นความปลอดภัยสำหรับการแบ่งปันทรัพยากรข้ามแหล่งกำเนิด ) อย่างน้อยก็ไม่ถ้าเราเชื่อมั่นว่าข้อมูลจำเพาะ W3C จะถูกนำไปใช้อย่างถูกต้องในเบราว์เซอร์สมัยใหม่ทั้งหมด (เราทำได้ไหม)

แต่คำขอประเภทอื่น ๆ เช่นส่งแบบฟอร์มล่ะ? กำลังโหลดแท็ก script / img / ... ? หรือวิธีอื่นใดที่เพจสามารถใช้เพื่อสร้างคำขอ (ตามกฎหมาย) ได้? หรือบางคนอาจรู้จักแฮ็ค JS?

หมายเหตุ: ฉันไม่ได้พูดถึง

• แอปพลิเคชันเนทีฟ
• เบราว์เซอร์ที่มีการจัดการ
• ข้อบกพร่องการเขียนสคริปต์ข้ามไซต์ในหน้าของ example.com
• ...

โปรดทราบว่าสิ่งนี้ไม่ควรเป็นไปได้กับ XHR (ดูเช่นความปลอดภัยสำหรับการแบ่งปันทรัพยากรข้ามแหล่งกำเนิด) อย่างน้อยก็ไม่หากเราเชื่อมั่นว่าข้อกำหนด W3C จะนำไปใช้อย่างถูกต้องในเบราว์เซอร์สมัยใหม่ทั้งหมด (ทำได้หรือไม่)

ในตอนท้ายของวันคุณต้อง "ไว้วางใจ" เบราว์เซอร์ไคลเอนต์เพื่อจัดเก็บข้อมูลของผู้ใช้อย่างปลอดภัยและปกป้องเซสชันฝั่งไคลเอ็นต์ หากคุณไม่ไว้วางใจเบราว์เซอร์ไคลเอนต์คุณควรหยุดใช้เว็บเลยสำหรับสิ่งอื่นที่ไม่ใช่เนื้อหาคงที่ ถึงแม้จะมีการใช้ราชสกุล CSRF คุณจะไว้วางใจเบราว์เซอร์ของลูกค้าได้อย่างถูกต้องเชื่อฟังเดียวกันนโยบายแหล่งกำเนิดสินค้า

แม้ว่าจะมีช่องโหว่ของเบราว์เซอร์ก่อนหน้านี้เช่นในIE 5.5 / 6.0ซึ่งเป็นไปได้ที่ผู้โจมตีจะข้ามนโยบายแหล่งกำเนิดเดียวกันและดำเนินการโจมตีโดยทั่วไปคุณสามารถคาดหวังว่าสิ่งเหล่านี้จะได้รับการแก้ไขทันทีที่ค้นพบและเบราว์เซอร์ส่วนใหญ่จะอัปเดตโดยอัตโนมัติ ความเสี่ยงนี้ส่วนใหญ่จะบรรเทาลง

แต่คำขอประเภทอื่น ๆ เช่นส่งแบบฟอร์มล่ะ? กำลังโหลดแท็ก script / img / ... ? หรือวิธีอื่นใดที่เพจสามารถใช้เพื่อสร้างคำขอ (ตามกฎหมาย) ได้? หรือบางคนอาจรู้จักแฮ็ค JS?

โดยOriginปกติส่วนหัวจะถูกส่งสำหรับคำขอข้ามโดเมน XHR เท่านั้น คำขอรูปภาพไม่มีส่วนหัว

หมายเหตุ: ฉันไม่ได้พูดถึง

• แอปพลิเคชันเนทีฟ

• เบราว์เซอร์ที่มีการจัดการ

• ข้อบกพร่องการเขียนสคริปต์ข้ามไซต์ในหน้าของ example.com

ฉันไม่แน่ใจว่าสิ่งนี้อยู่ภายใต้เบราว์เซอร์ที่ถูกควบคุมหรือไม่ แต่Flash เวอร์ชันเก่าอนุญาตให้ตั้งค่าส่วนหัวโดยพลการซึ่งจะทำให้ผู้โจมตีสามารถส่งคำขอพร้อมrefererส่วนหัวที่ปลอมแปลงจากเครื่องของเหยื่อเพื่อทำการโจมตีได้

เนื้อหาเว็บไม่สามารถแทรกแซงส่วนหัว Origin ได้ นอกจากนี้ภายใต้นโยบายต้นทางเดียวกันจุดเริ่มต้นหนึ่งไม่สามารถส่งส่วนหัวที่กำหนดเองไปยังต้นทางอื่นได้ [1]

ดังนั้นการตรวจสอบส่วนหัว Origin จึงสามารถบล็อกการโจมตีได้ดีพอ ๆ กับการใช้โทเค็น CSRF

ข้อกังวลหลักในการพึ่งพาสิ่งนี้คือการอนุญาตให้คำขอที่ถูกต้องตามกฎหมายทั้งหมดทำงานได้หรือไม่ ผู้ถามทราบเกี่ยวกับปัญหานี้และได้ตั้งคำถามเพื่อแยกแยะกรณีสำคัญ ๆ ออกไป (ไม่มีเบราว์เซอร์เก่า HTTPS เท่านั้น)

ผู้จำหน่ายเบราว์เซอร์ปฏิบัติตามกฎเหล่านี้ แต่สิ่งที่เกี่ยวกับปลั๊กอิน? อาจไม่ได้ แต่คำถามไม่สนใจ "เบราว์เซอร์ที่ถูกปรับเปลี่ยน" แล้วจุดบกพร่องในเบราว์เซอร์ที่ทำให้ผู้โจมตีปลอมแปลงส่วนหัว Origin ล่ะ? อาจมีข้อบกพร่องที่ทำให้โทเค็น CSRF รั่วไหลข้ามต้นกำเนิดได้เช่นกันดังนั้นจึงต้องใช้เวลามากขึ้นในการโต้แย้งว่าอันหนึ่งดีกว่าอีกอันหนึ่ง