בידוד בין מקורות (CORS) והגנה מפני דליפות באתרים שונים במהלך אינטראקציה עם חלונות קופצים.
ערך חדש זמין למדיניות פותחן מרובות מקורות (COOP): restrict-properties
. הוא מספק יתרונות אבטחה ומקל על השימוש בבידוד בין מקורות, תוך מתן אפשרות לאתר שלכם לקיים אינטראקציה עם חלונות קופצים של צד שלישי לצורך תשלומים, אימות או תרחישי שימוש אחרים.
כדי להתחיל להתנסות ב-restrict-properties
, צריך להשתתף בגרסת המקור לניסיון החל מ-Chrome 116.
למה כדאי להשתמש ב-restrict-properties
יש שני תרחישים עיקריים לדוגמה לשימוש ב-restrict-properties
:
- מניעת הדלפות חוצות-אתרים בלי לשבור את האתר.
- הפיכת האתר למבודד ממקורות שונים.
מניעת הדלפות חוצות-אתרים בלי לשבור את הקוד
כברירת מחדל, כל אתר יכול לפתוח את האפליקציה בחלון קופץ ולקבל הפניה אליה.
אתר זדוני יכול לנצל את המצב הזה לטובתו כדי לבצע התקפות כמו דליפות בין אתרים.
כדי לצמצם את הסיכון הזה, אפשר להשתמש בכותרת Cross-Origin-Opener-Policy
(COOP).
עד עכשיו, האפשרויות שלכם ב-Cross-Origin-Opener-Policy
היו מוגבלות. תוכלו:
- מגדירים את
same-origin,
, שמחסום את כל האינטראקציות עם פריטים קופצים ממקורות שונים. - מגדירים את הערך
same-origin-allow-popups
, שחוסמ את כל האינטראקציות בין מקורות שפותחים את האתר בחלון קופץ. - מגדירים את הערך
unsafe-none
, שמאפשר את כל האינטראקציות עם פריטים קופצים ממקורות שונים.
כתוצאה מכך, לא ניתן היה לאכוף את ה-COOP באתרים שצריך לפתוח בחלון קופץ ולבצע אינטראקציה עם הגורם שפתח אותם. כתוצאה מכך, תרחישי שימוש מרכזיים כמו כניסה יחידה (SSO) ותשלומים לא היו מוגנים מפני דליפות בין אתרים.
Cross-Origin-Opener-Policy: restrict-properties
פותר את הבעיה הזו.
כשמשתמשים ב-restrict-properties
, לא זמינים מאפיינים שאפשר להשתמש בהם לספירת פריימים ולהתקפות אחרות של דליפות בין אתרים – אבל מותרת תקשורת בסיסית בין חלונות דרך postMessage
ו-closed
.
כך אפשר לשפר את האבטחה של האתר תוך שמירה על תרחישי שימוש עיקריים. לדוגמה:
- אם אתם מספקים שירות בחלון קופץ, ההגדרה
Cross-Origin-Opener-Policy: restrict-properties
תגן עליכם מפני מגוון התקפות של דליפות בין אתרים. עדיין תוכלו לפתוח את כל הדפים שפתחתם בעבר. - אם אתם צריכים לגשת לחלון קופץ ממקורות שונים, ההגדרה
Cross-Origin-Opener-Policy: restrict-properties
תעזור להגן על האתר שלכם מפני ספירה של iframe. תוכלו לפתוח את אותם חלונות קופצים שאפשר לפתוח היום. - אם גם הדף הפותח וגם הדף שנפתח מגדירים את הכותרת, והדפים הם ממקורות שונים, ההתנהגות דומה לזו של אחד מהם שהגדיר את הכותרת. אם הם מאותו מקור, ניתנת גישה מלאה.
איך מבודדים את האתר ממקורות שונים
למה אנחנו צריכים בידוד ממקורות שונים
ממשקי API מסוימים של אינטרנט מגדילים את הסיכון להתקפות בערוץ צדדי, כמו Spectre. כדי למזער את הסיכון, דפדפנים מציעים סביבה מבודדת מבוססת-הסכמה, שנקראת בידוד בין מקורות. במצב של בידוד בין מקורות, דף האינטרנט יכול להשתמש בתכונות עם הרשאות, כולל SharedArrayBuffer, performance.measureUserAgentSpecificMemory() ושעונים עם דיוק גבוה ברזולוציה טובה יותר, תוך בידוד המקור מאחרים, אלא אם הם הביעו הסכמה.
עד עכשיו, כדי להשתמש בממשקי ה-API האלה, צריך להגדיר את Cross-Origin-Opener-Policy:
same-origin
. עם זאת, הפעולה הזו תשבש כל תהליך קופץ בין מקורות שעשוי להידרש לכם, כמו כניסה יחידה (SSO) ותשלומים.
עכשיו אפשר להשתמש ב-Cross-Origin-Opener-Policy: restrict-properties
במקום ב-Cross-Origin-Opener-Policy: same-origin
כדי להפעיל בידוד בין מקורות.
במקום לנתק את הקשר של מי שפתח את הפנייה, הוא רק מגביל אותו לקבוצת המשנה המינימלית של התקשורת בין window.postMessage()
ל-window.closed
.
תהיה לכם אפשרות להפעיל בידוד ממקורות שונים עם שתי הכותרות הבאות:
Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp
או
Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless
מידע נוסף על credentialless
זמין במאמר טעינה של משאבים ממקורות שונים ללא כותרות CORP באמצעות COEP: credentialless
.
הדגמה (דמו)
תוכלו לנסות כמה אפשרויות לכותרות בהדגמה של בידוד בין מקורות.
ניסוי המקור לניסיון
כדי להתנסות ב-Cross-Origin-Opener-Policy: restrict-properties
, תוכלו להירשם לתקופת הניסיון של המקור.
תמיכה בדפדפנים
כרגע יש תמיכה ב-Cross-Origin-Opener-Policy: restrict-properties
רק ב-Chrome. דפדפנים אחרים מעורבים באופן פעיל בדיון בנושא סטנדרטיזציה.
שאלות נפוצות
האתר שלי צריך לתקשר עם חלונות קופצים מאותו מקור. האם כדאי להשתמש ב-COOP: restrict-properties
כדי להפעיל בידוד בין מקורות?
הגדרת COOP: restrict-properties
גם בחלון הקופץ וגם בדף הראשי לא תוביל להגבלות. הגדרה של postMessage
רק בחלון הקופץ או רק בדף הראשי תמנע גישה לנכסים אחרים מלבד postMessage
ו-closed
ב-opener, גם אם הם מאותו מקור.
האם קבוצת המאפיינים המותרים קבועה?
על סמך המשוב שקיבלנו עד עכשיו, אנחנו סבורים ש-window.postMessage
ו-window.closed
מספיקים לרוב תהליכי העבודה, אבל אנחנו עדיין שוקלים לפתוח את התכונה למלונות נוספים. אם יש לכם תרחיש שימוש שלא ניתן לפתור באמצעות postMessage
ו-closed
בלבד, תוכלו לשלוח את המשוב שלכם בשרשור Intent to Experiment.
משאבים
- איך מבודדים את האתר מ-origin שונים באמצעות COOP ו-COEP
- למה צריך 'בידוד בין מקורות' כדי לקבל תכונות מתקדמות
- מדריך להפעלת בידוד ממקורות שונים
- עדכוני SharedArrayBuffer ב-Chrome 88 ל-Android וב-Chrome 92 למחשב
- איך טוענים משאבים ממקורות שונים ללא כותרות CORP באמצעות
COEP: credentialless
– למפתחי Chrome - גרסת מקור של iframe אנונימי: הטמעה נוחה של מסגרות iframe בסביבות COEP – מפתחי Chrome