ทำไมจึงต้องใช้ "การแยกแบบข้ามต้นทาง" สำหรับฟีเจอร์ที่มีประสิทธิภาพ

ดูสาเหตุที่ต้องมีการแยกแบบข้ามต้นทางเพื่อใช้ฟีเจอร์ที่มีประสิทธิภาพ เช่น 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) ฟีเจอร์นี้ช่วยให้คุณประกาศ เอกสารไม่สามารถโหลดทรัพยากรดังกล่าว

วิธีการทำงานของ COEP

หากต้องการเปิดใช้นโยบายนี้ ให้เพิ่มส่วนหัว 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

COOP

ส่วนหัว Cross-Origin-Opener-Policy ใช้ค่าที่เป็นไปได้ 3 ค่าดังนี้

Cross-Origin-Opener-Policy: same-origin

เอกสารที่ทำเครื่องหมายว่า same-origin จะแชร์บริบทการท่องเว็บเดียวกันได้ กลุ่มที่มีเอกสารต้นทางเดียวกันซึ่งมีการทำเครื่องหมายเป็น same-origin อย่างชัดเจน

COOP

Cross-Origin-Opener-Policy: same-origin-allow-popups

เอกสารระดับบนสุดที่มี same-origin-allow-popups จะเก็บการอ้างอิงไปยัง ป๊อปอัปที่ไม่ได้ตั้งค่า COOP หรือเลือกไม่ใช้การแยกโดย ตั้งค่า COOP เป็น unsafe-none

COOP

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

แหล่งข้อมูล