ดูสาเหตุที่ต้องมีการแยกแบบข้ามต้นทางเพื่อใช้ฟีเจอร์ที่มีประสิทธิภาพ เช่น SharedArrayBuffer, performance.measureUserAgentSpecificMemory() และตัวจับเวลาแบบความละเอียดสูงที่มีความแม่นยำมากขึ้น
บทนำ
ในส่วนการทำให้เว็บไซต์ "แยกต้นทาง" ของคุณ โดยใช้ COOP และ COEP เราอธิบายวิธีการปรับใช้ "ข้ามต้นทาง" แยกต่างหาก" โดยใช้ COOP และ COEP นี่คือบทความเสริมที่อธิบาย ทำไมจึงต้องมีการแยกแบบข้ามต้นทางเพื่อเปิดใช้ฟีเจอร์ที่มีประสิทธิภาพในเบราว์เซอร์
ข้อมูลเบื้องต้น
เว็บสร้างขึ้นจากต้นทางเดียวกัน
นโยบาย: ฟีเจอร์ความปลอดภัยที่จำกัด
วิธีที่เอกสารและสคริปต์สามารถโต้ตอบกับทรัพยากรจากต้นทางอื่น ช่วงเวลานี้
หลักการนี้จะจำกัดวิธีการที่เว็บไซต์สามารถเข้าถึงทรัพยากรแบบข้ามต้นทาง สำหรับ
ตัวอย่างเช่น เอกสารจาก https://a.example ไม่สามารถเข้าถึงข้อมูล
โฮสต์ที่ https://b.example
อย่างไรก็ตาม นโยบายต้นทางเดียวกันมีข้อยกเว้นที่ผ่านมาบางประการ ทุกเว็บไซต์สามารถ:
- ฝัง iframe แบบข้ามต้นทาง
- รวมทรัพยากรแบบข้ามต้นทาง เช่น รูปภาพหรือสคริปต์
- เปิดหน้าต่างป๊อปอัปแบบข้ามต้นทางด้วยการอ้างอิง DOM
หากคุณออกแบบเว็บใหม่ตั้งแต่ต้น จะไม่มีข้อยกเว้นเหล่านี้ แต่เมื่อชุมชนเว็บได้ทราบถึงประโยชน์หลักๆ ของ นโยบายต้นทางเดียวกันที่เข้มงวด เว็บได้ใช้ข้อยกเว้นเหล่านี้อยู่แล้ว
ผลข้างเคียงด้านความปลอดภัยของนโยบายต้นทางเดียวกันแบบ Lax ดังกล่าวได้รับการแพตช์ออกเป็น 2 ส่วน
ได้ วิธีหนึ่งคือการเปิดตัวโปรโตคอลใหม่ที่ชื่อว่าครอส
การแชร์ทรัพยากรต้นทาง (CORS)
ซึ่งทำหน้าที่ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์อนุญาตให้แบ่งปันทรัพยากรกับ
ที่มา อีกวิธีหนึ่งคือการนำการเข้าถึงสคริปต์โดยตรงออกโดยปริยาย
ทรัพยากรแบบข้ามต้นทางขณะที่รักษาความเข้ากันได้แบบย้อนหลัง เช่น
ทรัพยากรแบบข้ามต้นทางจะเรียกว่า "ทึบแสง" ที่ไม่ซับซ้อน ตัวอย่างเช่น นี่เป็นเหตุผล
การจัดการพิกเซลของรูปภาพแบบข้ามต้นทางผ่าน CanvasRenderingContext2D
ไม่สำเร็จ เว้นแต่ว่าจะมีการใช้ CORS กับอิมเมจ
การตัดสินใจเกี่ยวกับนโยบายทั้งหมดเหล่านี้เกิดขึ้นภายในกลุ่มบริบทของการท่องเว็บ
การรวม CORS และทรัพยากรที่คลุมเครือมาเป็นเวลานานก็เพียงพอที่จะทำให้ เบราว์เซอร์ที่ปลอดภัย บางครั้ง Edge Case (เช่น JSON ช่องโหว่) ถูกค้นพบ และจำเป็นต้องได้รับการแพตช์ แต่โดยรวมแล้วหลักการที่ว่า การอนุญาตการเข้าถึงการอ่านไบต์ดิบของทรัพยากรแบบข้ามต้นทางโดยตรง สำเร็จ
ทั้งหมดนี้เปลี่ยนแปลงด้วย
Spectre ซึ่ง
ทำให้ข้อมูลที่โหลดไปยังกลุ่มบริบทการท่องเว็บเดียวกับโค้ดของคุณ
ให้ผู้ใช้อ่านได้ การวัดเวลาที่ใช้ในการดำเนินการบางอย่างทำให้ผู้โจมตี
สามารถคาดเดาเนื้อหาแคช CPU ได้ และผ่านการควบคุมเนื้อหา
กระบวนการ" ความทรงจำ การโจมตีแบบกะทันหันนี้อาจเกิดขึ้นได้โดยใช้ตัวจับเวลาที่มีความละเอียดต่ำ
ที่มีอยู่ในแพลตฟอร์ม แต่เร่งความเร็วได้ด้วยตัวจับเวลาที่ละเอียดยิ่งขึ้น
ทั้งชัดแจ้ง (เช่น performance.now()) และโดยนัย (เช่น
SharedArrayBuffer) หาก evil.com ฝังรูปภาพแบบข้ามต้นทาง ก็อาจใช้
การโจมตีที่น่ากลัวเพื่ออ่านข้อมูลพิกเซล ซึ่งทำให้การป้องกันต้องอาศัย
"ความทึบแสง" ไม่มีประสิทธิภาพ
ตามหลักการ คำขอแบบข้ามต้นทางทั้งหมดควรได้รับการตรวจสอบอย่างชัดแจ้งโดยเซิร์ฟเวอร์ ที่เป็นเจ้าของทรัพยากร หากไม่ได้ทำการตรวจสอบภายใน เซิร์ฟเวอร์ที่เป็นเจ้าของทรัพยากร ข้อมูลก็จะไม่มีวันเข้าสู่การท่องเว็บ กลุ่มบริบทของผู้กระทำความชั่วร้าย ดังนั้น จึงไม่เอื้อต่อการโจมตีของสเปคเตอร์ การโจมตีหน้าเว็บหนึ่งๆ ที่อาจเกิดขึ้นได้ เราเรียกว่าสถานะที่แยกออกมาแบบข้ามต้นทาง นี่เป็นเรื่องเกี่ยวกับ COOP+COEP
ภายใต้สถานะแยกแบบข้ามต้นทาง เว็บไซต์ที่ส่งคำขอจะถือว่าน้อยกว่า
เป็นอันตราย และทำให้คุณได้รับฟีเจอร์ที่มีประสิทธิภาพ เช่น SharedArrayBuffer
performance.measureUserAgentSpecificMemory()และความละเอียดสูง
ตัวจับเวลาที่แม่นยำขึ้น
มิฉะนั้นจะใช้สำหรับการโจมตีแบบสเปคเตอร์ และยังช่วยป้องกันการปรับเปลี่ยน
document.domain
นโยบายเครื่องมือฝังแบบข้ามต้นทาง
เครื่องมือฝังแบบข้ามต้นทาง นโยบาย (COEP) จะป้องกันไม่ให้ เอกสารไม่ให้โหลดทรัพยากรแบบข้ามต้นทางที่ไม่ได้ระบุไว้อย่างชัดเจน สิทธิ์ในเอกสาร (โดยใช้ CORP หรือ CORS) ฟีเจอร์นี้ช่วยให้คุณประกาศ เอกสารไม่สามารถโหลดทรัพยากรดังกล่าว
หากต้องการเปิดใช้นโยบายนี้ ให้เพิ่มส่วนหัว HTTP ต่อไปนี้ในเอกสาร
Cross-Origin-Embedder-Policy: require-corp
คีย์เวิร์ด require-corp เป็นค่าเดียวที่ระบบยอมรับสําหรับ COEP การดำเนินการนี้บังคับใช้
นโยบายที่เอกสารสามารถโหลดเฉพาะทรัพยากรที่มาจากต้นทางเดียวกัน หรือ
ทรัพยากรที่ระบุอย่างชัดเจนว่าสามารถโหลดได้จากต้นทางอื่น
ทรัพยากรต้องรองรับการโหลดจากต้นทางอื่นจึงจะโหลดได้ Cross Origin Resource Share (CORS) หรือนโยบายทรัพยากรที่ข้ามต้นทาง (CORP)
การแชร์ทรัพยากรข้ามโดเมน
หากทรัพยากรแบบข้ามต้นทางรองรับการแชร์ทรัพยากรข้ามโดเมน
(CORS) คุณสามารถใช้
crossorigin
แอตทริบิวต์
เพื่อโหลดหน้าเว็บได้โดยไม่ถูกบล็อกโดย COEP
<img src="https://third-party.example.com/image.jpg" crossorigin>
ตัวอย่างเช่น หากทรัพยากรรูปภาพนี้มาพร้อมกับส่วนหัว CORS ให้ใช้
แอตทริบิวต์ crossorigin เพื่อที่คำขอดึงข้อมูลทรัพยากรจะใช้ CORS
โหมด ยัง
ป้องกันไม่ให้โหลดรูปภาพ เว้นแต่จะตั้งค่าส่วนหัว CORS
ในทำนองเดียวกัน คุณอาจดึงข้อมูลข้ามต้นทางผ่านเมธอด fetch() ซึ่ง
ไม่จำเป็นต้องมีการจัดการพิเศษ ตราบใดที่เซิร์ฟเวอร์ตอบสนอง
HTTP
ส่วนหัว
นโยบายทรัพยากรข้ามโดเมน
นโยบายทรัพยากรข้ามโดเมน (บริษัท) แรกเริ่มเป็นการเลือกใช้เพื่อปกป้องทรัพยากรของคุณ ซึ่งโหลดโดยต้นทางอื่น ในบริบทของ COEP CORP จะระบุทรัพยากรได้ นโยบายของเจ้าของเกี่ยวกับผู้ที่สามารถโหลดทรัพยากร
ส่วนหัว Cross-Origin-Resource-Policy ใช้ค่าที่เป็นไปได้ 3 ค่าดังนี้
Cross-Origin-Resource-Policy: same-site
ทรัพยากรที่มีเครื่องหมาย same-site จะโหลดได้จากเว็บไซต์เดียวกันเท่านั้น
Cross-Origin-Resource-Policy: same-origin
ทรัพยากรที่มีเครื่องหมาย same-origin จะโหลดได้จากต้นทางเดียวกันเท่านั้น
Cross-Origin-Resource-Policy: cross-origin
เว็บไซต์ทั้งหมดสามารถโหลดทรัพยากรที่มีเครื่องหมาย cross-origin ได้ (
ระบบจะเพิ่มค่า
ข้อกำหนดของ CORP และ COEP)
นโยบายเครื่องมือเปิดแบบข้ามต้นทาง
นโยบายเครื่องมือเปิดแบบข้ามต้นทาง
(COOP) ทำให้คุณมั่นใจได้ว่า
ว่าหน้าต่างระดับบนสุดจะแยกออกจากเอกสารอื่นๆ โดยใส่ไว้ในไฟล์
กลุ่มบริบทต่างๆ ในการเรียกดู เพื่อไม่ให้สามารถโต้ตอบกับ
หน้าต่างระดับบนสุด ตัวอย่างเช่น หากเอกสารที่มี COOP เปิดป๊อปอัป ระบบจะ
พร็อพเพอร์ตี้ window.opener จะเป็น null นอกจากนี้ พร็อพเพอร์ตี้ .closed ของ
การอ้างอิงของเครื่องมือเปิดจะแสดงผลเป็น true
ส่วนหัว Cross-Origin-Opener-Policy ใช้ค่าที่เป็นไปได้ 3 ค่าดังนี้
Cross-Origin-Opener-Policy: same-origin
เอกสารที่ทำเครื่องหมายว่า same-origin จะแชร์บริบทการท่องเว็บเดียวกันได้
กลุ่มที่มีเอกสารต้นทางเดียวกันซึ่งมีการทำเครื่องหมายเป็น same-origin อย่างชัดเจน
Cross-Origin-Opener-Policy: same-origin-allow-popups
เอกสารระดับบนสุดที่มี same-origin-allow-popups จะเก็บการอ้างอิงไปยัง
ป๊อปอัปที่ไม่ได้ตั้งค่า COOP หรือเลือกไม่ใช้การแยกโดย
ตั้งค่า COOP เป็น unsafe-none
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none คือค่าเริ่มต้น และอนุญาตให้เพิ่มเอกสารลงใน
การเรียกดูกลุ่มบริบท เว้นแต่ตัวเปิดจะมี COOP เป็น same-origin
สรุป
หากต้องการเข้าถึงฟีเจอร์ที่มีประสิทธิภาพอย่าง SharedArrayBuffer อย่างแน่นอน
performance.measureUserAgentSpecificMemory()หรือความละเอียดสูง
ตัวจับเวลาที่แม่นยำกว่า แต่อย่าลืมที่จะ
เอกสารของคุณต้องใช้ COEP ทั้ง 2 แบบที่มีค่า require-corp และ
COOP ที่มีค่า same-origin หากไม่มีรายการใดรายการหนึ่ง เบราว์เซอร์จะ
ไม่ได้รับประกันว่าจะมีการแยกตัวอย่างเพียงพอต่อการเปิดใช้ฟีเจอร์ที่มีประสิทธิภาพเหล่านั้นได้อย่างปลอดภัย คุณ
ทราบถึงสถานการณ์ของหน้าเว็บได้ด้วยการตรวจสอบว่า
self.crossOriginIsolated
แสดงผล true
ดูขั้นตอนในการใช้งานได้ที่การทำเว็บไซต์ "ข้ามต้นทาง" แยกต่างหาก" การใช้ COOP และ COEP