מפתחים שמשתמשים ב-COEP יכולים עכשיו להטמיע מסגרות iframe של צד שלישי שלא משתמשות ב-COEP בעצמם.
iframe ללא פרטי כניסה מופעל כברירת מחדל מ-Chrome בגרסה 110. הפתרון הזה פותר את הבעיות הנפוצות ביותר שמפתחים עובדים עם המדיניות Cross-Origin-Embedder-Policy (COEP): הטמעת מסגרות iframe של צד שלישי שלא מגדירות COEP.
למה אנחנו צריכים את COEP
חלק מממשקי ה-API באינטרנט מגדילים את הסיכון להתקפות ערוץ צדדי כמו Spectre. כדי למזער את הסיכון, דפדפנים מציעים סביבה מבודדת מבוססת הסכמה שנקראת בידוד בין מקורות, שמחייבת פריסה של COEP. בידוד ממקורות שונים מאפשר לאתרים להשתמש בתכונות שדורשות הרשאות, כולל SharedArrayBuffer
, performance.measureUserAgentSpecificMemory()
וטיימרים ברמת דיוק גבוהה עם רזולוציה טובה יותר.
כדי להפעיל בידוד בין מקורות, אתרים חייבים לשלוח את כותרות ה-HTTP הבאות:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
אפשר גם להשתמש בפרמטר COEP:credentialless כחלופה ל-require-corp
. פרטים נוספים זמינים במסמכי התיעוד.
האתגרים בהפעלת COEP
בידוד בין מקורות משפר את האבטחה של דפי אינטרנט ואת היכולת להפעיל תכונות מתקדמות, אבל הפריסה של COEP עשויה להיות קשה. אחד האתגרים הגדולים ביותר הוא שכל iframes ממקורות שונים צריכים לפרוס COEP ו-CORP. הדפדפן לא יטען תמונות iframe ללא הכותרות האלה.
שימוש ב-Iframe ללא פרטי כניסה כדי להציל
אנחנו משיקים את <iframe credentialless>
כדי לעזור בהטמעת מסגרות iframe של צד שלישי שלא מגדירות COEP. הוספת המאפיין credentialless
לרכיב <iframe>
תוביל לטעינה של ה-iframe מהקשר אחר וריק. באופן ספציפי, הוא נטען ללא קובצי cookie. כך אפשר להסיר את ההגבלה ב-COEP.
דוגמה:
<iframe credentialless src="https://example.com">
ה-iframe הזה נוצר בהקשר זמני חדש ואין לו גישה לאף אחד מקובצי ה-cookie שמשויכים לאתר ברמה העליונה. במקום זאת, הוא מתחיל בצנצנת עוגיות ריקה. באופן דומה, ממשקי API של Storage כמו LocalStorage, CacheStorage , IndexedDB וכן הלאה, טוענים ומאחסנים נתונים במחיצה הזמנית החדשה. המחיצה היא בהיקף של המסמך הנוכחי ברמה העליונה וגם של מקור ה-iframe. לאחר הסרת המסמך ברמה העליונה, כל נפח האחסון הזה ינוקה.
מסגרות iframe ללא פרטי כניסה לא כפופות לכללי ההטמעה של COEP. הם עדיין מאובטחים: הם נטענים מהקשר חדש וריק בכל פעם, ולכן הם לא אמורים להכיל נתונים מותאמים אישית, שזו המטרה של התוקפים. אם iframe מכיל רק נתונים ציבוריים, הוא לא בעל ערך לתוקפים.
הדגמה (דמו)
אפשר לראות הדגמה של iframe ללא פרטי כניסה.
שאלות נפוצות
האם דפדפנים אחרים יאמצו את התכונה הזו?
האם <iframe>
נמצא בתוך נכס <iframe credentialless>
ללא פרטי כניסה?
כן. היא עוברת בירושה. כאשר ל-iframe אין פרטי כניסה, המאפיין יחול על כל מסגרות ה-iframe בכל עץ המשנה, גם ללא המאפיין credentialless
.
האם גם חלונות קופצים נוצרים מ-<iframe credentialless>
ללא פרטי כניסה?
חלונות קופצים נפתחים כאילו הוגדרה המדיניות noopener
. הם נוצרים בהקשר חדש ברמה העליונה רגילה, והם לא ללא פרטי כניסה. הם לא יכולים לתקשר עם ה-iframe ללא פרטי הכניסה.
איך לזהות שהמסמך הוטמע ב-iframe ללא פרטי כניסה?
window.credentialless
מוגדר כ-true בתוך iframe ללא פרטי כניסה. אחרת, הערך הוא False. הערך שלו הוא undefined
בדפדפן אינטרנט שלא תומך ב-<iframe credentialless>
.
משאבים
- הפיכת האתר ל"מבודד ממקורות שונים" באמצעות COOP ו-COEP
- למה צריך 'בידוד בין מקורות' לתכונות מתקדמות
- מדריך להפעלת בידוד ממקורות שונים
- עדכונים ב-SharedArrayBuffer ב-Android Chrome 88 וב-Chrome למחשב
- טעינה של משאבים ממקורות שונים בלי כותרות CORP באמצעות
COEP: credentialless
- IFrame ללא פרטי כניסה - אבטחת אינטרנט | MDN