จุดประสงค์ของส่วนหัว X-Requested-With คืออะไร


224

JQuery และกรอบงานอื่น ๆ เพิ่มหัวข้อต่อไปนี้:

X- ร้องขอด้วย: XMLHttpRequest

ทำไมถึงจำเป็น เหตุใดเซิร์ฟเวอร์จึงต้องการจัดการคำขอ AJAX แตกต่างจากคำขอปกติ

UPDATE : ฉันเพิ่งพบเป็นตัวอย่างในชีวิตจริงโดยใช้ส่วนหัวนี้: https://core.spreedly.com/manual/payment-methods/adding-with-js หากมีการร้องขอตัวประมวลผลการชำระเงินโดยไม่มี AJAX ตัวประมวลผลการชำระเงินจะเปลี่ยนเส้นทางกลับไปยังเว็บไซต์ดั้งเดิมเมื่อดำเนินการเสร็จ เมื่อมีการร้องขอด้วย AJAX จะไม่มีการเปลี่ยนเส้นทาง


7
"[เมื่อ] ร้องขอโดยไม่มี AJAX มันเปลี่ยนเส้นทางกลับไปที่เว็บไซต์ดั้งเดิมเมื่อดำเนินการเสร็จเมื่อมีการร้องขอด้วย AJAX จะไม่มีการเปลี่ยนเส้นทาง" -> นั่นคือเหตุผลที่คุณต้องการทำเช่นนั้น :)
Robert Christian

คำตอบ:


258

เหตุผลที่ดีสำหรับการรักษาความปลอดภัย - นี้สามารถป้องกันCSRFโจมตีเพราะส่วนหัวนี้ไม่สามารถเพิ่มการร้องขอ AJAX ข้ามโดเมนโดยปราศจากความยินยอมของเซิร์ฟเวอร์ผ่านทางธ

เฉพาะส่วนหัวต่อไปนี้ได้รับอนุญาตข้ามโดเมน:

  • ยอมรับ
  • ยอมรับภาษา
  • เนื้อหาภาษา
  • ล่าสุดเหตุการณ์-ID
  • ชนิดของเนื้อหา

ผู้อื่นทำให้เกิดคำขอ "การบินล่วงหน้า" ที่จะออกในเบราว์เซอร์ที่รองรับ CORS

หากไม่มี CORS จะไม่สามารถเพิ่มลงX-Requested-Withในคำขอ XHR ข้ามโดเมนได้

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

ค้นพบการเลี่ยงผ่านแฟลชใหม่

คุณอาจต้องการที่จะรวมนี้กับโทเค็นเพราะแฟลชทำงานบน Safari บน OSX สามารถตั้งค่าส่วนหัวนี้ว่ามีขั้นตอนการเปลี่ยนเส้นทาง ปรากฏว่าใช้งานได้กับ Chromeแต่ได้รับการแก้ไขแล้ว รายละเอียดเพิ่มเติมที่นี่รวมถึงเวอร์ชันอื่น ๆ ที่ได้รับผลกระทบ

OWASP แนะนำให้รวมสิ่งนี้กับเช็ค Origin และ Referer :

เทคนิคการป้องกันนี้ถูกกล่าวถึงโดยเฉพาะในหัวข้อ 4.3 ของการป้องกันที่แข็งแกร่งสำหรับการปลอมแปลงคำขอข้ามไซต์ อย่างไรก็ตามการข้ามการป้องกันนี้โดยใช้ Flash ได้รับการบันทึกเป็นช่วงต้นปี 2008 และอีกครั้งในปี 2015 โดย Mathias Karlsson เพื่อใช้ประโยชน์จากข้อบกพร่อง CSRF ใน Vimeo แต่เราเชื่อว่าการโจมตีด้วยแฟลชไม่สามารถหลอกลวงส่วนหัวของแหล่งกำเนิดสินค้าหรือผู้อ้างอิงได้ดังนั้นโดยการตรวจสอบทั้งคู่เราเชื่อว่าการรวมกันของการตรวจสอบนี้จะช่วยป้องกันการโจมตีผ่านทาง CSRF ของ Flash (หมายเหตุ: หากใครสามารถยืนยันหรือปฏิเสธความเชื่อนี้โปรดแจ้งให้เราทราบเพื่อให้เราสามารถอัปเดตบทความนี้)

อย่างไรก็ตามด้วยเหตุผลที่กล่าวถึงการตรวจสอบ Origin อาจเป็นเรื่องยุ่งยาก

ปรับปรุง

เขียนเพิ่มเติมในเชิงลึกเกี่ยวกับการโพสต์บล็อกธ , CSRF และ X-ขอกับที่นี่


14
ฉันไม่เข้าใจ อะไรจะป้องกันผู้โจมตีจากการสร้างคำขอและเพิ่มX-Requested-Withส่วนหัวด้วย?
Greg

13
@Greg: เบราว์เซอร์ - ไม่อนุญาตให้ข้ามโดเมน
SilverlightFox

2
โอ้ฉันไม่ทราบว่าจะต้องใช้ CORS ตราบเท่าที่คุณอยู่ในโดเมนเดียวกัน เห็นได้ชัดว่าเมื่อคุณคิดเกี่ยวกับมัน ขอบคุณมาก!
Greg

10
@ vol7ron: ไม่มีอะไรจะหยุดพวกเขา แต่พวกเขาจะไม่มีคุกกี้ของเหยื่อในคำขอที่เอาชนะวัตถุของพวกเขาในการร้องขอ เพื่อให้ CSRF ประสบความสำเร็จผู้โจมตีจะต้องใช้เบราว์เซอร์เพื่อแนบคุกกี้โดยอัตโนมัติพร้อมกับคำขอดังนั้นหากไม่มีเบราว์เซอร์จะไม่มีการโจมตี CSRF
SilverlightFox

3
@ vol7ron: อดีต CSRF เป็นปัญหารองที่สับสน เบราว์เซอร์เป็นรองสับสนและ "หลอก" ในการส่งคุกกี้เพื่อขอผู้ใช้ไม่ได้ทำด้วยตัวเอง
SilverlightFox

25

ตรวจสอบให้แน่ใจว่าคุณอ่านคำตอบของ SilverlightFox มันเน้นเหตุผลที่สำคัญกว่า

เหตุผลส่วนใหญ่คือถ้าคุณทราบที่มาของคำขอคุณอาจต้องการปรับแต่งเล็กน้อย

ตัวอย่างเช่นสมมติว่าคุณมีเว็บไซต์ที่มีสูตรอาหารมากมาย และคุณใช้เฟรมเวิร์ก jQuery ที่กำหนดเองเพื่อเลื่อนสูตรไปยังคอนเทนเนอร์ตามลิงก์ที่คลิก ลิงค์อาจจะwww.example.com/recipe/apple_pie

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

ตอนนี้คุณสามารถเขียนจุดปลายรองสำหรับข้อมูลที่ชอบwww.example.com/recipe_only/apple_pieแต่นั่นยากที่จะรักษาและแบ่งปันให้กับผู้อื่น

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

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

มันคล้ายกับAccept-Languageส่วนหัวจริงๆ เบราว์เซอร์สามารถขอเว็บไซต์โปรดแสดงเวอร์ชันรัสเซียของเว็บไซต์นี้โดยไม่ต้องแทรก / ru / หรือคล้ายกันใน URL


30
ว้าวฟังดูเหมือนฝันร้ายในการบำรุงรักษาที่น่ากลัว หากคุณต้องการส่งคืนการแสดงต่าง ๆ ของเพจเดียวกันคุณควรระบุประเภทเนื้อหาที่แตกต่างให้กับAcceptส่วนหัว การใช้ส่วนหัวที่กำหนดเองสำหรับฟังดูเหมือนผิดวิธี
Gili

10

เฟรมเวิร์กบางตัวใช้ส่วนหัวนี้เพื่อตรวจจับการร้องขอ xhr เช่นการรักษาความปลอดภัยของ grails spring กำลังใช้ส่วนหัวนี้เพื่อระบุการร้องขอ xhr และให้การตอบสนอง json หรือการตอบสนอง HTML เป็นการตอบสนอง

ไลบรารี Ajax ส่วนใหญ่ (Prototype, JQuery และ Dojo ณ v2.1) มีส่วนหัว X-Requested-With ที่ระบุว่าการร้องขอนั้นทำโดย XMLHttpRequest แทนที่จะถูกทริกเกอร์โดยการคลิกที่ไฮเปอร์ลิงก์ปกติหรือปุ่มส่งแบบฟอร์ม

ที่มา: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.