הפיכת האתר שלך "מבודד ממקורות שונים" באמצעות COOP ו-COEP

בעזרת COOP ו-COEP, ניתן להגדיר סביבה מבודדת ממקורות שונים ולהפעיל תכונות מתקדמות כמו SharedArrayBuffer, performance.measureUserAgentSpecificMemory() וטיימר ברזולוציה גבוהה ברמת דיוק גבוהה יותר.

עדכונים

  • 21 ביוני 2022: צריך לטפל גם בסקריפטים של Worker במקרים של בידוד ממקורות שונים מופעלת. הוספנו כמה הסברים.
  • 5 באוגוסט 2021: API ליצירת פרופיל עצמי של JS הוזכר כאחד מממשקי ה-API נדרשת בידוד ממקורות שונים, אבל באופן שמשקף שינוי שבוצע לאחרונה כיוון יחד, הוא הוסר.
  • 6 במאי 2021: על סמך המשוב והבעיות שדווחו, החלטנו לבצע שינויים ציר הזמן לשימוש של SharedArrayBuffer באף אתר מבודד ממקורות שונים יוגבלו ב-Chrome M92.
  • 16 באפריל 2021: נוספו הערות לגבי תוכנית COEP חדשה ללא פרטי כניסה מצב ו-COOP הופעה של חלונות קופצים באותו מקור תנאי לנתוני מקורות של טרנספורמר.
  • 5 במרץ 2021: הוסרו המגבלות של SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), ופונקציות של ניפוי באגים, אשר מופעלות כעת באופן מלא ב-Chrome 89. נוספו יכולות חדשות, performance.now() ו-performance.timeOrigin, הערכים האלה יהיו גבוהים יותר המדויק.
  • 19 בפברואר 2021: נוספה הערה לגבי המדיניות בנושא תכונות allow="cross-origin-isolated" ופונקציונליות לניפוי באגים בכלי הפיתוח.
  • 15 באוקטובר 2020: self.crossOriginIsolated זמין ב-Chrome 87. לפי הממצאים, document.domain לא ניתן לשינוי כאשר הפונקציה self.crossOriginIsolated מחזירה true. גרסת המקור לניסיון של performance.measureUserAgentSpecificMemory() מסתיימת מופעלת כברירת מחדל ב-Chrome 89. מאגר המערך המשותף ב-Android Chrome יהיו זמינים ב-Chrome 88.

חלק מממשקי ה-API באינטרנט מגדילים את הסיכון למתקפות בערוץ צדדי כמו Spectre. שפת תרגום כדי למזער את הסיכון, דפדפנים מציעים סביבה מבודדת מבוססת-הסכמה שנקראת מבודד ממקורות שונים. בדף האינטרנט במצב מבודד ממקורות שונים, תוכלו להשתמש בתכונות שדורשות הרשאות, כולל:

API תיאור
SharedArrayBuffer נדרש לשרשורים של WebAssembly. התכונה הזו זמינה ב-Android Chrome 88. גרסת שולחן העבודה מופעלת כרגע כברירת מחדל עם עזרה מתוך בידוד של אתר, אבל יהיה צורך להשתמש במצב בידוד בין מקורות ו- יושבת כברירת מחדל ב-Chrome 92.
performance.measureUserAgentSpecificMemory() זמין ב-Chrome בגרסה 89.
performance.now(), performance.timeOrigin זמין בשלב זה בדפדפנים רבים עם הרזולוציה מוגבלת ל- 100 מיקרו-שניות או יותר. עם בידוד ממקורות שונים, הפרמטר הרזולוציה יכולה להיות עד 5 מיקרו-שניות.
תכונות שיהיו זמינות מאחורי גישה מבודדת ממקורות שונים .

המצב המבודד ממקורות שונים מונע גם שינויים של document.domain (היכולת לשנות את document.domain מאפשרת תקשורת בין מסמכים באותו אתר, ונחשבת לפרצת אבטחה מדיניות המקור הזהה.)

כדי להביע הסכמה למצב בידוד בין מקורות, צריך לשלוח את הפרטים הבאים כותרות HTTP במסמך הראשי:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

הכותרות האלה מנחים את הדפדפן לחסום טעינה של משאבים או מסגרות iframe שלא בחרו להיטען באמצעות מסמכים ממקורות שונים, ומונעים מחלונות מקורות שונים מאינטראקציה ישירה עם המסמך. גם המשמעות היא שהמשאבים שנטענים ממקורות שונים מחייבים הבעת הסכמה.

ניתן לקבוע אם דף אינטרנט נמצא במצב מבודד ממקורות שונים על ידי: בדיקה self.crossOriginIsolated

במאמר הזה נסביר איך להשתמש בכותרות החדשות האלה. בהודעת המשך מאמר אני אספק עוד רקע והקשר.

פריסת COOP ו-COEP כדי שהאתר יהיה מבודד ממקורות שונים

שילוב COOP ו-COEP

1. הגדרת הכותרת Cross-Origin-Opener-Policy: same-origin במסמך ברמה העליונה

על ידי הפעלת COOP: same-origin במסמך ברמה העליונה, חלונות עם אותם במקור, ובחלונות שנפתחו מהמסמך, תתבצע גלישה נפרדת קבוצת הקשר, אלא אם הם באותו מקור עם אותה הגדרת COOP. כך, הבידוד נאכף בחלונות פתוחים ובתקשורת הדדית שני החלונות מושבתים.

קבוצת הקשר של גלישה היא קבוצה של חלונות שיכולים להפנות זה לזה. עבור למשל, מסמך ברמה עליונה ומסמכי הצאצא שלו שמוטמעים דרך <iframe>. אם באתר (https://a.example) נפתח חלון קופץ (https://b.example), כך חלון הפתיחה והחלון הקופץ חולקים את אותו הקשר גלישה, יש להם גישה אחד לשני דרך ממשקי DOM API כמו window.opener.

קבוצת הקשר של עיון

אפשר לבדוק אם פותח החלון והפותח שלו נמצאים בגלישה נפרדת קבוצות הקשר מכלי הפיתוח.

2. בדיקה שהמשאבים של CORP או CORS מופעלים

צריך לוודא שכל המשאבים בדף נטענים באמצעות CORP או CORS HTTP כותרות עליונות. השלב הזה נדרש לשלב הרביעי, הפעלת COEP.

אלה הפעולות שצריך לבצע בהתאם לאופי המשאב:

  • אם המשאב צפוי להיטען רק מאותו המקור, מגדירים הכותרת Cross-Origin-Resource-Policy: same-origin.
  • אם המשאב צפוי להיטען רק מאותו אתר, אבל origin, מגדירים את הכותרת Cross-Origin-Resource-Policy: same-site.
  • אם המשאב נטען ממקורות שונים בשליטתכם, עליכם להגדיר כותרת Cross-Origin-Resource-Policy: cross-origin, אם אפשר.
  • למשאבים בין מקורות שאין לכם שליטה עליהם:
    • משתמשים במאפיין crossorigin בתג ה-HTML של הטעינה אם המשאב עם CORS. (לדוגמה, <img src="***" crossorigin>).
    • צריך לבקש מהבעלים של המשאב לתמוך ב-CORS או ב-CORP.
  • לגבי iframes, עליכם לפעול לפי אותם העקרונות שמפורטים למעלה ולהגדיר Cross-Origin-Resource-Policy: cross-origin (או same-site, same-origin בהתאם להקשר).
  • סקריפטים שנטענים באמצעות WebWorker חייבים להיות מוצגים מאותו מקור. כך שלא צריך כותרות CORP או CORS.
  • למסמך או לעובד שנשלח באמצעות COEP: require-corp, במשאבי משנה שנטענים בלי CORS, חייבים להגדיר את הכותרת Cross-Origin-Resource-Policy: cross-origin כדי להסכים להטמעה. לדוגמה, חל על <script>, importScripts, <link>, <video>, <iframe> וכו'

3. הערכת משאבים מוטמעים באמצעות כותרת ה-HTTP בדוח COEP בלבד

לפני ההפעלה המלאה של COEP, אפשר להריץ הרצה יבשה באמצעות הכותרת Cross-Origin-Embedder-Policy-Report-Only כדי לבדוק אם המדיניות עובד בפועל. יישלחו אליך דוחות בלי לחסום תוכן מוטמע.

מוחל באופן רקורסיבי על כל המסמכים, כולל המסמך ברמה העליונה, iframes וסקריפטים של worker. למידע על כותרת HTTP לדיווח בלבד, אפשר לעיין בכתובת זיהוי בעיות באמצעות הדוחות API.

4. הפעלת COEP

לאחר שמוודאים שהכול עובד, ושכל המשאבים נטען בהצלחה, צריך להחליף את Cross-Origin-Embedder-Policy-Report-Only לכותרת Cross-Origin-Embedder-Policy עם אותו ערך לכולם מסמכים, כולל אלה שמוטמעים באמצעות iframes וסקריפטים של worker.

החליטו אם הבידוד הצליח בעזרת self.crossOriginIsolated

הנכס self.crossOriginIsolated מחזיר true כשדף האינטרנט נמצא מצב מבודד בין מקורות וכל המשאבים והחלונות מבודדים אותה קבוצת הקשר של גלישה. אפשר להשתמש ב-API הזה כדי לקבוע אם הצלחנו לבודד בהצלחה את קבוצת ההקשר של הגלישה ולקבל גישה אל בתכונות מתקדמות כמו performance.measureUserAgentSpecificMemory().

ניפוי באגים באמצעות כלי הפיתוח ל-Chrome

זה די קל למשאבים שמעובדים במסך כמו תמונות. כדי לזהות בעיות ב-COEP כי הבקשה תיחסם והדף לציין תמונה חסרה. עם זאת, לגבי משאבים שלא עשויות להיות השפעה על ההיבטים החזותיים, כמו סקריפטים או סגנונות, עשויות להיות בעיות ב-COEP נעלמים. כדי להשתמש בהם, אפשר להשתמש בחלונית של כלי הפיתוח. אם המיקום יש בעיה עם COEP, אתם יכולים לראות (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) בסטטוס עמודה.

בעיות ב-COEP בעמודה Status (סטטוס) בחלונית &#39;רשת&#39;.

לאחר מכן אפשר ללחוץ על הרשומה כדי לראות פרטים נוספים.

פרטים על בעיית COEP מוצגים בכרטיסייה &#39;כותרות&#39; אחרי לחיצה על משאב רשת בחלונית &#39;רשת&#39;.

אפשר גם לקבוע את הסטטוס של iframes וחלונות קופצים באמצעות החלונית אפליקציה. נכנסים לקטע 'מסגרות'. בצד שמאל, הרחבת החלק העליון של הדף כדי לראות את הפירוט של מבנה המשאב.

אפשר לבדוק את הסטטוס של ה-iframe, כמו הזמינות של SharedArrayBuffer, וכו'

הכלי לבדיקת iframe של כלי פיתוח ל-Chrome

אפשר גם לבדוק את הסטטוס של החלונות הקופצים, למשל אם מדובר בכמה מקורות. מבודדת.

הכלי לבדיקת החלונות הקופצים של כלי הפיתוח ל-Chrome

זיהוי בעיות באמצעות Reporting API

Reporting API הוא מנגנון נוסף שבאמצעותו אפשר זיהוי בעיות שונות. אפשר להגדיר את Reporting API כדי להנחות את משתמשים דפדפן כדי לשלוח דוח בכל פעם ש-COEP חוסם את הטעינה של משאב או COOP מבודדים חלון קופץ. Chrome תומך ב-Reporting API מאז גרסה 69 למגוון שימושים, כולל COEP ו-COOP.

כדי ללמוד איך להגדיר את Reporting API ולהגדיר שרת שיקבל עבור הדוחות, עבור אל שימוש בדוחות API.

דוח COEP לדוגמה

דוגמה של COEP דוח המטען הייעודי (payload) כשמשאב ממקורות שונים חסום נראה כך:

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]

דוח COOP לדוגמה

דוגמה של COOP report מטען ייעודי (payload) כשחלון קופץ נפתח מבודד נראה כך:

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

כאשר קבוצות הקשר שונות של גלישה מנסות לגשת זו אל זו (רק "דוח בלבד" ), COOP שולח גם דוח. לדוגמה, דיווח כאשר הניסיון לבצע postMessage() ייראה כך:

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

סיכום

שימוש בשילוב של כותרות COOP ו-COEP HTTP כדי לצרף דף אינטרנט מצב מבודד ממקורות שונים. תוכלו לבדוק self.crossOriginIsolated כדי לקבוע אם דף אינטרנט נמצא במקורות שונים מצב מבודד.

הפוסט הזה יתעדכן כשיהיו תכונות חדשות זמינות מצב מבודד ממקורות שונים, ושיפורים נוספים בכלי הפיתוח מתבצעים סביב COOP ו-COEP.

משאבים