לעיתים קרובות, משאבים ממקורות שונים שמוצגים על ידי צדדים שלישיים לא כוללים כותרות מתאימות של CORP. אם אפשר לבקש אותם ללא פרטי כניסה, עכשיו אפשר להפעיל בידוד בין מקורות על ידי סימון שלהם ככאלה.
שלחנו את הערך credentialless של מדיניות ההטמעה ממקורות שונים (COEP), כדי לאפשר לדפדפן לטעון משאבים ממקורות שונים שלא משתמשים במדיניות המשאבים בין מקורות (CORP), על ידי שליחת בקשה ללא פרטי כניסה, כמו קובצי cookie. כך המפתחים יכולים לעבור בקלות לבידוד בין מקורות.
למה צריך לחסום מקורות שונים
חלק מממשקי ה-API לאינטרנט מגבירים את הסיכון להתקפות בערוץ צדדי כמו Spectre. כדי למזער את הסיכון, דפדפנים מציעים סביבה מבודדת שמבוססת על הסכמה שנקראת בידוד בין מקורות. במצב בידוד בין מקורות, דף האינטרנט יכול להשתמש בתכונות מהרשאות, כולל SharedArrayBuffer, performance.measureUserAgentSpecificMemory() וטיימרים ברמת דיוק גבוהה ברזולוציה טובה יותר, תוך בידוד המקור מגורמים אחרים, אלא אם הם מביעים הסכמה לכך.
דף האינטרנט צריך לשלוח שתי כותרות HTTP כדי לאפשר בידוד בין מקורות:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
במצב מבודד ממקורות שונים, יש להציג את כל המשאבים ממקורות שונים עם CORS או להגדיר טעינה של הכותרת Cross-Origin-Resource-Policy.
האתגרים שמאפשרים בידוד בין מקורות
בידוד בין מקורות מגביר את האבטחה של דפי האינטרנט ואת היכולת להפעיל תכונות מתקדמות, אבל הפריסה שלו יכולה להיות קשה. אחד האתגרים הגדולים ביותר הוא הדרישה להפעיל CORS או CORP בכל המשאבים ממקורות שונים. משאבים ללא הכותרות האלה לא ייטענו על ידי הדפדפן בדף מבודד ממקורות שונים.
המשאבים ממקורות שונים בדרך כלל מקבלים שירות על ידי צדדים שלישיים, ויכול להיות שלא יהיה קל להוסיף להם את הכותרות הנדרשות.
אבל מה אם אנחנו יודעים שהמשאב בטוח מספיק כדי לטעון אותו? למעשה, המשאבים היחידים שנמצאים בסיכון הם משאבים שנדרשים באמצעות פרטי כניסה, כי הם עלולים לכלול מידע רגיש שהתוקפים לא יכולים לטעון בעצמו. המשמעות היא שמשאבים שאפשר לבקש בלי פרטי כניסה זמינים לציבור והטעינה שלהם בטוחה.
credentialless באים להצלה
כאן COEP: credentialless נכנס לתמונה. credentialless הוא ערך חדש לכותרת Cross-Origin-Embedder-Policy. בדומה ל-require-corp, היא יכולה להפעיל בידוד בין מקורות, אבל במקום לדרוש כותרת CORP:cross-origin לבקשות ממקורות שונים ללא קורס, הן נשלחות ללא פרטי כניסה (למשל קובצי cookie).
תוכלו גם להפעיל בידוד בין מקורות באמצעות שתי הכותרות הבאות:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
המשמעות היא שהשרת המבוקש בין המקורות לא יוכל להגיב באמצעות משאב רגיש, ומגיש הבקשה תמיד יוכל להניח שהתשובה מכילה רק מידע שזמין באופן ציבורי.
הנחיה זו תואמת גם לתוכנית של דפדפנים להוצאה משימוש בהדרגה של קובצי Cookie של צד שלישי.
הדגמה (דמו)
בהדגמה הזו תוכלו לנסות אפשרויות שונות לכותרת: https://cross-origin-isolation.glitch.me
שאלות נפוצות
אפשר לשלוח בקשה עם פרטי כניסה בסביבה credentialless?
כמובן, במחיר של שינוי מצב הבקשה כך שתדרוש בדיקת CORS על התגובה. לתגי HTML כמו <audio>, <img>, <link>, <script> ו-<video>, צריך רק להוסיף crossorigin="use-credentials" באופן מפורש כדי ליידע את הדפדפן לשלוח בקשות עם פרטי כניסה.
לדוגמה, גם אם למסמך ב-https://www.example.com יש כותרת Cross-Origin-Embedder-Policy: credentialless, תישלח בקשה על ידי <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials"> עם פרטי כניסה.
עבור API fetch(), ניתן להשתמש ב-request.mode = 'cors'.
סופק COEP: credentialless, איך COEP: require-corp עדיין שימושי לאתר שלי?
ב-COEP: require-corp לא צריך להחליף באופן ידני את מצב הבקשה ל-CORS אם נדרשים קובצי cookie במשאבי משנה מסוימים ממקורות שונים.
האם אפשר לטעון גם מסגרות iframe ממקורות שונים ללא כותרות מיוחדות בסביבת credentialless?
לא. טעינת iframes ממקורות שונים בסביבת credentialless עדיין דורשת את אותם התנאים כמו require-corp. למסמכי iframe יש להציג שתי כותרות:
Cross-Origin-Embedder-Policy: credentialless(אוrequire-corp)Cross-Origin-Resource-Policy: cross-origin
החדשות הטובות הן שיש דיון מתמשך לגבי מתן הרשאה לטעינת מסגרות iframe ממקורות שונים ללא הכותרות האלה על ידי מתן crossorigin="anonymous" ל-iframes.
זה יאפשר טעינה של מסגרות iframe ממקורות שונים בלי כותרות אבל בלי פרטי כניסה.
האם דפדפנים אחרים ישתמשו בתכונה הזו?
- בעיה במעקב ב-Firefox
- בקשת Webkit למיקום: אין אות
- תג W3C בקשה למיקום: בהמתנה
המאמרים הבאים
יש שני עדכונים נוספים שנועדו לצמצם אתגרים אחרים שקשורים לבידוד בין מקורות:
בגלל המכשולים שצוינו למעלה, אנשים שנרשמו לגרסת המקור לניסיון של Chrome כדי להאריך את השינוי ב-SharedArrayBuffer מתי היא תסתיים. במקור הודענו שהוא יסתיים בגרסה 96 של Chrome, אבל החלטנו לדחות את ההודעה לגרסה 106 של Chrome.
משאבים
- הפיכת האתר ל'מבודד ממקורות שונים' באמצעות COOP ו-COEP
- למה צריך להגדיר בידוד בין מקורות כדי להשתמש בתכונות מתקדמות
- מדריך להפעלת בידוד בין מקורות
- עדכונים של SharedArrayBuffer ב-Android Chrome 88 וב-Chrome 92 למחשבים
תמונה מאת מרטין אדמס ב-UnFlood