เซิร์ฟเวอร์ของฉันคาดว่าจะส่งคืน 200 สำหรับวิธี HTTP OPTIONS เมื่อจุดเชื่อมต่อถูกห้ามให้กับผู้ใช้ปัจจุบันหรือไม่

การอ่านเอกสารต่างๆ (เช่น w3c CORS) ฉันต้องบอกว่า OPTIONS ทำ ดูเหมือนจะไม่ได้รับการบันทึกไว้อย่างดีเลย

ฉันสงสัยว่าเซิร์ฟเวอร์ REST ของฉันทำถูกต้องหรือไม่ ซึ่งจะส่งคืน 403 หากไคลเอนต์พยายามเข้าถึงจุดเชื่อมต่อที่ถูกห้าม (ไม่ว่าจะมีอยู่หรือไม่ก็ตาม ไม่สำคัญเสมอไป แม้ว่าในบางครั้งเซิร์ฟเวอร์อาจส่งคืน 404 แทน.)

อย่างไรก็ตาม ดูเหมือนว่าเอกสารประกอบ OPTIONS ไม่ได้อนุมานว่าโค้ดส่งคืนนั้นถูกต้อง

ฉันพบ stackoverflow Q/A นี้ ซึ่งคำตอบที่ได้รับการยอมรับดูเหมือนว่าจะบอกว่าเราสามารถส่งคืนรหัสข้อผิดพลาดใดๆ ได้

ฉันคิดว่ามันจะเป็นช่องโหว่ด้านความปลอดภัยที่จะอนุญาตให้ OPTIONS ทะลุผ่านได้เมื่อผู้ใช้ไม่ได้รับอนุญาต ในเวลาเดียวกัน OPTIONS กำหนดส่วนหัว Access-Control-Allow-Credentials และฉันไม่เห็นว่าจะทำให้ส่วนหัวนั้นมีประโยชน์ได้อย่างไรหากฉันส่งคืน 403 บนจุดเชื่อมต่อดังกล่าว (หรืออีกนัยหนึ่งสำหรับฉันมันฟังดูขัดแย้งกัน)


http rest cors http-method
person Alexis Wilke    schedule 29.01.2019    source แหล่งที่มา
comment
และจริงๆ แล้ว หากฉันตรวจพบ 403 ในระหว่างทาง ฉันก็จะสามารถสร้างส่วนหัว Access-Control-Allow-Credentials ที่จุดนั้นได้   -  person Alexis Wilke    schedule 29.01.2019

คำตอบ (1)


arrow_upward
2
arrow_downward

คำตอบสั้นๆ: หากคุณต้องการให้การตอบสนองของ OPTIONS มีประโยชน์จริง ๆ เท่าที่เปิดใช้งาน CORS เซิร์ฟเวอร์ คุณไม่ควรส่งคืน 403 เพียงเพราะผู้ใช้ไม่ได้เข้าสู่ระบบ

รายละเอียด:

ไม่ถูกต้องเลยที่เซิร์ฟเวอร์จะส่งคืน 403 สำหรับคำขอ OPTIONS โปรโตคอล CORS ไม่ต้องการให้เซิร์ฟเวอร์ของคุณส่งคืนการตอบกลับที่สำเร็จ 2xx สำหรับคำขอ OPTIONS แต่หากเซิร์ฟเวอร์ของคุณ ไม่ ส่งคืนคำขอ 2xx สำหรับ OPTIONS ไปยัง URL หนึ่งๆ คำขอ CORS preflight OPTIONS ไปยัง URL นั้นจะล้มเหลว ดังนั้น หากนั่นคือสิ่งที่คุณต้องการ ต้องการให้ เกิดขึ้นจริง การตอบกลับด้วย 403 ก็เป็นเรื่องปกติ — ดังนั้น การตอบกลับด้วย 405 หรือ 501 หรือรหัสตอบกลับอื่นใดที่อาจมีความหมายเหมาะสมกับกรณีของคุณโดยเฉพาะ

แต่สิ่งสำคัญคือต้องจำไว้ว่าโปรโตคอล CORS กำหนดให้เบราว์เซอร์ไม่ต้องส่งข้อมูลรับรองการตรวจสอบสิทธิ์โดยเป็นส่วนหนึ่งของคำขอ CORS preflight OPTIONS ดังนั้น หากเซิร์ฟเวอร์ของคุณได้รับการกำหนดค่าให้ต้องมีการตรวจสอบสิทธิ์เพื่อให้คำขอ OPTIONS คำขอสร้างการตอบกลับที่สำเร็จ 2xx ครั้ง ดังนั้น preflight CORS ทั้งหมดที่มาจากเบราว์เซอร์จะล้มเหลว 100% ของเวลาทั้งหมด กล่าวอีกนัยหนึ่ง คุณจะต้องแน่ใจว่าคำขอทั้งหมดจะล้มเหลวซึ่งมาถึงเซิร์ฟเวอร์จากโค้ด JavaScript ส่วนหน้าที่ทำงานในเบราว์เซอร์ และเพิ่มส่วนหัวการตอบกลับที่กำหนดเอง (เช่น Content-Type หรือ Authorization ส่วนหัว) และเพื่อให้ทริกเกอร์ preflights

ฉันไม่ทราบถึงช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้นจากการตอบกลับด้วย 2xx ต่อคำขอ OPTIONS ที่ไม่ได้รับการรับรองความถูกต้อง (จากผู้ใช้ที่ไม่ได้รับอนุญาต) ซึ่งจะไม่อนุญาตให้ผู้ใช้รับข้อมูลใดๆ จากเซิร์ฟเวอร์ของคุณ นอกเหนือจากสิ่งที่คุณตั้งใจเลือกที่จะใส่ลงในส่วนหัวการตอบกลับที่คุณส่งเพื่อตอบสนองต่อคำขอ OPTIONS และแน่นอนว่ามันไม่ได้ป้องกันคุณจากการกำหนดการรับรองความถูกต้องสำหรับ GET หรือ POST หรือวิธีอื่นใด แต่ในแง่ของโปรโตคอล CORS นี่เป็นวิธีเดียวที่เซิร์ฟเวอร์ของคุณจะสามารถระบุวิธีการและส่วนหัวของคำขอที่อนุญาตในคำขอจาก JavaScript ส่วนหน้า

หมายเหตุด้วย: ข้อกำหนดที่ได้รับการบำรุงรักษาในปัจจุบันสำหรับ CORS ได้รับการกำหนดไว้ในข้อมูลจำเพาะ Fetch https://fetch.spec.whatwg.org. ข้อมูลจำเพาะของ https://w3.org/TR/cors ล้าสมัยและไม่ได้รับการบำรุงรักษาอีกต่อไป และไม่ควร' ใช้สำหรับอะไรก็ได้ (ดู https://w3.org/2017/08/16-webappsec-minutes.html#item03 และคำตอบที่ https://stackoverflow.com/a/45926657/441757)

ฉันไม่รู้ว่าทำไมข้อมูลจำเพาะของ https://w3.org/TR/cors ไม่ใช่ มีการทำเครื่องหมายว่าล้าสมัยอย่างชัดเจนแล้ว แต่ฉันจะพยายามให้แน่ใจว่าจะถูกทำเครื่องหมายในไม่ช้า

person sideshowbarker    schedule 29.01.2019
comment
ใช่แล้ว ขอให้โชคดีที่ทำให้สิ่งนั้นเกิดขึ้น ครั้งล่าสุดที่ฉันได้ยิน (จาก @annevk) ไม่มีใครที่ W3 สามารถทำเครื่องหมายว่าล้าสมัยได้ ดังนั้นมันจึงนั่งอยู่ตรงนั้น โปรดทราบว่าฉันคิดว่าในบางแง่เอกสาร W3 นั้นเขียนได้ดีกว่าสำหรับนักพัฒนาส่วนหน้า - ข้อมูลจำเพาะ Fetch นั้นเขียนขึ้นสำหรับนักพัฒนาเบราว์เซอร์จริงๆ... - person roryhewitt; 04.02.2019