ตอนนี้นักพัฒนาซอฟต์แวร์ที่ใช้ COEP สามารถฝัง iframe ของบุคคลที่สามที่ไม่ได้ใช้ COEP เองได้แล้ว
เปิดใช้งาน Iframe แบบไม่มีข้อมูลเข้าสู่ระบบโดยค่าเริ่มต้นจาก Chrome เวอร์ชัน 110 โซลูชันนี้ช่วยแก้ปัญหาด้านการร้องเรียนที่นักพัฒนาซอฟต์แวร์ซึ่งทำงานโดยใช้ cross-Origin-Embedder-Policy (COEP) พบบ่อยที่สุด เช่น การฝัง iframe ของบุคคลที่สามที่ไม่ได้ตั้งค่า COEP
เหตุผลที่เราต้องมี COEP
API ของเว็บบางเว็บอาจเพิ่มความเสี่ยงที่จะเกิดการโจมตีแบบ Side-channel เช่น Spectre เบราว์เซอร์เสนอสภาพแวดล้อมแบบแยกที่อิงตามการเลือกใช้ที่เรียกว่าการแยกแบบข้ามต้นทาง ซึ่งจำเป็นต้องทำให้ COEP ใช้งานได้ เพื่อลดความเสี่ยงดังกล่าว การแยกข้ามต้นทางช่วยให้เว็บไซต์ใช้ฟีเจอร์ที่ได้รับสิทธิ์ เช่น SharedArrayBuffer
, performance.measureUserAgentSpecificMemory()
และตัวจับเวลาที่มีความแม่นยำสูงพร้อมความละเอียดที่ดีกว่า
หากต้องการเปิดใช้การแยกแบบข้ามต้นทาง เว็บไซต์ต้องส่งส่วนหัว HTTP ต่อไปนี้
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
COEP:credentialless ใช้แทน require-corp
ได้ ดูรายละเอียดเพิ่มเติมในเอกสารประกอบ
ความท้าทายของการเปิดใช้ COEP
แม้ว่าการแยกแบบข้ามต้นทางจะทำให้หน้าเว็บมีความปลอดภัยยิ่งขึ้นและความสามารถในการเปิดใช้ฟีเจอร์ที่มีประสิทธิภาพ แต่การใช้งาน COEP อาจเป็นเรื่องยาก ปัญหาที่ใหญ่ที่สุดอย่างหนึ่งคือ iframe แบบข้ามต้นทางทั้งหมดจะต้องทำให้ COEP และ CORP ใช้งานได้ เบราว์เซอร์จะไม่โหลด iframe ที่ไม่มีส่วนหัวเหล่านั้น
ไม่มีข้อมูลเข้าสู่ระบบ iframe เพื่อการช่วยชีวิต
เรากำลังจะเปิดตัว <iframe credentialless>
เพื่อช่วยฝัง iframe ของบุคคลที่สามที่ไม่ได้ตั้งค่า COEP เมื่อเพิ่มแอตทริบิวต์ credentialless
ลงในองค์ประกอบ <iframe>
ระบบจะโหลด iframe จากบริบทที่ว่างเปล่าอื่น โดยเฉพาะอย่างยิ่ง ระบบสามารถโหลดโดยไม่มีคุกกี้ ซึ่งจะทำให้นำข้อจำกัด COEP ออกได้
ตัวอย่าง
<iframe credentialless src="https://example.com">
iframe นี้สร้างขึ้นในบริบทชั่วคราวใหม่ และไม่มีสิทธิ์เข้าถึงคุกกี้ใดๆ ที่เชื่อมโยงกับเว็บไซต์ระดับบนสุด แต่จะเริ่มต้นด้วยโหลคุกกี้เปล่า ในทำนองเดียวกัน API พื้นที่เก็บข้อมูล เช่น LocalStorage, CacheStorage, IndexedDB และอื่นๆ จะโหลดและจัดเก็บข้อมูลในพาร์ติชันชั่วคราวใหม่ พาร์ติชันมีขอบเขตทั้งเอกสารระดับบนสุดปัจจุบันและต้นทางของ iframe ระบบจะล้างพื้นที่เก็บข้อมูลนี้ทั้งหมดเมื่อยกเลิกการโหลดเอกสารระดับบนสุด
iframe ที่ไม่มีข้อมูลเข้าสู่ระบบไม่ได้อยู่ภายใต้กฎการฝัง COEP การป้องกันเหล่านี้ยังคงปลอดภัย เนื่องจากจะถูกโหลดจากบริบทใหม่ที่ว่างเปล่าทุกครั้ง จึงไม่ควรมีข้อมูลที่ปรับเปลี่ยนในแบบของผู้โจมตี ซึ่งก็คือการโจมตีต่อไป หาก iframe มีเฉพาะข้อมูลสาธารณะ จะถือว่าไม่มีประโยชน์สำหรับผู้โจมตี
สาธิต
คุณดูการสาธิตของ iframe ที่ไม่มีข้อมูลเข้าสู่ระบบได้
คำถามที่พบบ่อย
จะมีการใช้งานฟีเจอร์นี้ในเบราว์เซอร์อื่นๆ ด้วยไหม
- คำขอ Mozilla สำหรับตำแหน่ง: รอดำเนินการ
- คำขอตำแหน่ง Webkit: ไม่มีสัญญาณ
- แท็ก W3C คำขอตำแหน่ง: พอใจ
<iframe>
ฝังอยู่ในข้อมูลเข้าสู่ระบบ <iframe credentialless>
หรือไม่
ได้ เพราะเป็นองค์ประกอบที่สืบทอดกันมา เมื่อ iframe ไม่มีข้อมูลเข้าสู่ระบบ ซึ่งจะนําไปใช้กับ iframe ทั้งหมดในซับทรีแม้จะไม่มีแอตทริบิวต์ credentialless
ป๊อปอัปที่สร้างขึ้นจาก <iframe credentialless>
เป็นแบบไม่มีข้อมูลเข้าสู่ระบบด้วยไหม
ป๊อปอัปจะเปิดขึ้นเสมือนว่าตั้งค่า noopener
แล้ว โดยสร้างขึ้นในบริบทระดับบนสุดแบบใหม่ตามปกติและไม่ใช่ข้อมูลเข้าสู่ระบบ ผู้ใช้จะสื่อสารกับ iframe ที่ไม่มีข้อมูลเข้าสู่ระบบไม่ได้
วิธีตรวจหาเอกสารถูกฝังใน iframe ที่ไม่มีข้อมูลเข้าสู่ระบบ
window.credentialless
เป็นจริงใน iframe ที่ไม่มีข้อมูลรับรองและจะเป็นเท็จหากไม่เป็นเช่นนั้น ค่าคือ undefined
ในเว็บเบราว์เซอร์ที่ไม่รองรับ <iframe credentialless>
แหล่งข้อมูล
- การทำให้เว็บไซต์ "แยกต้นทาง" ของคุณ การใช้ COOP และ COEP
- เหตุใดจึงต้องมี "แยกต่างหากแบบข้ามต้นทาง" สำหรับฟีเจอร์ที่มีประสิทธิภาพ
- คำแนะนำในการเปิดใช้การแยกแบบข้ามต้นทาง
- การอัปเดต SharedArrayBuffer ใน Android Chrome 88 และ Chrome 92 ในเดสก์ท็อป
- โหลดทรัพยากรแบบข้ามต้นทางที่ไม่มีส่วนหัว CORP โดยใช้
COEP: credentialless
- ไม่มีข้อมูลเข้าสู่ระบบ iframe - การรักษาความปลอดภัยบนเว็บ | MDN