เมื่อเร็ว ๆ นี้ฉันต้องตั้งค่าAccess-Control-Allow-Originเป็น*เพื่อให้สามารถโทร ajax ข้ามโดเมนย่อยได้
ตอนนี้ฉันอดไม่ได้ที่จะรู้สึกว่ากำลังทำให้สภาพแวดล้อมเสี่ยงต่อความปลอดภัย
โปรดช่วยฉันด้วยถ้าฉันทำผิด

ด้วยการตอบสนองAccess-Control-Allow-Origin: *ทรัพยากรที่ร้องขอจะอนุญาตให้แชร์กับทุกแหล่ง โดยทั่วไปหมายความว่าไซต์ใด ๆ สามารถส่งคำขอ XHR ไปยังไซต์ของคุณและเข้าถึงการตอบสนองของเซิร์ฟเวอร์ซึ่งจะไม่เป็นเช่นนั้นหากคุณไม่ได้ใช้การตอบสนอง CORS นี้

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

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

Access-Control-Allow-Origin: *มีความปลอดภัยโดยสิ้นเชิงที่จะเพิ่มลงในทรัพยากรใด ๆเว้นแต่ทรัพยากรนั้นจะมีข้อมูลส่วนตัวที่ได้รับการปกป้องโดยสิ่งอื่นที่ไม่ใช่ข้อมูลรับรองมาตรฐาน (คุกกี้, การรับรองความถูกต้องพื้นฐาน, ใบรับรองไคลเอ็นต์ TLS)

เช่น: ข้อมูลที่ได้รับการปกป้องโดยคุกกี้นั้นปลอดภัย

ลองนึกภาพhttps://example.com/users-private-dataซึ่งอาจเปิดเผยข้อมูลส่วนตัวขึ้นอยู่กับสถานะการเข้าสู่ระบบของผู้ใช้ สถานะนี้ใช้คุกกี้เซสชัน มันปลอดภัยที่จะเพิ่มAccess-Control-Allow-Origin: *ให้กับทรัพยากรนี้เป็นส่วนหัวนี้จะช่วยให้สามารถเข้าถึงการตอบสนองถ้าขอจะทำโดยไม่ต้องคุกกี้และคุกกี้จะต้องได้รับข้อมูลส่วนตัว ด้วยเหตุนี้จึงไม่มีข้อมูลส่วนตัวรั่วไหล

เช่น: ข้อมูลที่ป้องกันโดยตำแหน่ง / IP / เครือข่ายภายในไม่ปลอดภัย (น่าเสียดายที่มักเกิดกับอินทราเน็ตและเครื่องใช้ภายในบ้าน):

ลองนึกภาพhttps://intranet.example.com/company-private-dataซึ่งเปิดเผยข้อมูลของ บริษัท เอกชน แต่จะเข้าถึงได้ก็ต่อเมื่อคุณอยู่ในเครือข่าย wifi ของ บริษัท มันไม่ปลอดภัยที่จะเพิ่มAccess-Control-Allow-Origin: *ให้กับทรัพยากรนี้มันได้รับการคุ้มครองโดยใช้สิ่งอื่นนอกเหนือจากข้อมูลประจำตัวของมาตรฐาน มิฉะนั้นสคริปต์ที่ไม่ดีอาจใช้คุณเป็นช่องสัญญาณไปยังอินทราเน็ต

หลักการง่ายๆ

ลองนึกภาพว่าผู้ใช้จะเห็นอะไรหากพวกเขาเข้าถึงทรัพยากรในหน้าต่างที่ไม่ระบุตัวตน หากคุณพอใจที่ทุกคนเห็นเนื้อหานี้ (รวมถึงซอร์สโค้ดที่เบราว์เซอร์ได้รับ) คุณสามารถเพิ่มAccess-Control-Allow-Origin: *ได้อย่างปลอดภัย

AFAIK, Access-Control-Allow-Origin เป็นเพียงส่วนหัว http ที่ส่งจากเซิร์ฟเวอร์ไปยังเบราว์เซอร์ การ จำกัด ไว้เฉพาะที่อยู่ (หรือการปิดใช้งาน) ไม่ได้ทำให้ไซต์ของคุณปลอดภัยขึ้นสำหรับโรบ็อต หากโรบ็อตต้องการก็สามารถเพิกเฉยต่อส่วนหัวได้ เบราว์เซอร์ทั่วไปที่มีอยู่ (Explorer, Chrome และอื่น ๆ ) โดยค่าเริ่มต้นจะใช้ส่วนหัว แต่แอปพลิเคชันอย่างPostmanก็เพิกเฉย

จุดสิ้นสุดของเซิร์ฟเวอร์ไม่ได้ตรวจสอบว่า "ต้นทาง" คืออะไรเมื่อส่งคืนการตอบกลับ เพียงแค่เพิ่มส่วนหัว http เป็นเบราว์เซอร์ (ส่วนท้ายไคลเอ็นต์) ซึ่งส่งคำขอที่ตัดสินใจอ่านส่วนหัวการควบคุมการเข้าถึงและดำเนินการตามนั้น โปรดทราบว่าในกรณีของ XHR อาจใช้คำขอ 'OPTIONS' พิเศษเพื่อขอส่วนหัวก่อน

ดังนั้นใครก็ตามที่มีความสามารถในการเขียนสคริปต์อย่างสร้างสรรค์สามารถเพิกเฉยต่อส่วนหัวทั้งหมดได้ไม่ว่าจะตั้งค่าอะไรก็ตาม

ดูเพิ่มเติมปัญหาด้านความปลอดภัยที่เป็นไปได้ของการตั้งค่าการเข้าถึงการควบคุมอนุญาตให้-แหล่งกำเนิดสินค้า

ตอนนี้เพื่อตอบคำถามจริง

ฉันอดไม่ได้ที่จะรู้สึกว่ากำลังทำให้สภาพแวดล้อมเสี่ยงต่อความปลอดภัย

หากใครต้องการโจมตีคุณก็สามารถข้าม Access-Control-Allow-Origin ได้อย่างง่ายดาย แต่ด้วยการเปิดใช้งาน '*' คุณจะต้องเพิ่ม 'เวกเตอร์การโจมตี' ให้กับผู้โจมตีอีกสองสามอย่างเช่นใช้เว็บเบราว์เซอร์ปกติที่ให้เกียรติส่วนหัว HTTP นั้น

นี่คือ 2 ตัวอย่างที่โพสต์เป็นความคิดเห็นเมื่อสัญลักษณ์แทนมีปัญหาจริงๆ:

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

- แบรด

สมมติว่าคุณมีเราเตอร์ทั่วไปในบ้านเช่น Linksys WRT54g หรืออะไรสักอย่าง สมมติว่าเราเตอร์อนุญาตการร้องขอข้ามแหล่งกำเนิด สคริปต์บนหน้าเว็บของฉันสามารถส่งคำขอ HTTP ไปยังที่อยู่ IP ของเราเตอร์ทั่วไป (เช่น 192.168.1.1) และกำหนดค่าเราเตอร์ของคุณใหม่เพื่อให้สามารถโจมตีได้ มันยังสามารถใช้เราเตอร์ของคุณโดยตรงเป็น DDoS node (เราเตอร์ส่วนใหญ่มีหน้าทดสอบที่อนุญาตให้มีการ Ping หรือการตรวจสอบเซิร์ฟเวอร์ HTTP แบบง่ายสิ่งเหล่านี้สามารถใช้ในทางที่ผิดได้)

- แบรด

ฉันรู้สึกว่าความคิดเห็นเหล่านี้ควรเป็นคำตอบเพราะพวกเขาอธิบายปัญหาด้วยตัวอย่างชีวิตจริง

ในสถานการณ์ที่เซิร์ฟเวอร์พยายามปิดการใช้งาน CORS โดยสมบูรณ์โดยตั้งค่าด้านล่างส่วนหัว

• Access-Control-Allow-Origin: * (บอกเบราว์เซอร์ว่าเซิร์ฟเวอร์ยอมรับคำขอข้ามไซต์จาก ORIGIN ใด ๆ )

• Access-Control-Allow-Credentials: true (บอกเบราว์เซอร์ว่าคำขอข้ามไซต์สามารถส่งคุกกี้ได้)

มีการใช้งานความล้มเหลวที่ปลอดภัยในเบราว์เซอร์ซึ่งจะส่งผลให้เกิดข้อผิดพลาดด้านล่าง

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

ดังนั้นในสถานการณ์ส่วนใหญ่การตั้งค่า "Access-Control-Allow-Origin" เป็น*จะไม่มีปัญหา อย่างไรก็ตามเพื่อป้องกันการโจมตีเซิร์ฟเวอร์สามารถรักษารายการต้นกำเนิดที่อนุญาตและเมื่อใดก็ตามที่เซิร์ฟเวอร์ได้รับคำขอข้ามแหล่งที่มาก็สามารถตรวจสอบส่วนหัว ORIGIN กับรายการต้นกำเนิดที่อนุญาตแล้วสะท้อนกลับเหมือนเดิมใน Access-Control-Allow-Origin หัวข้อ.

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