אינטראקציות מאובטחות של חלונות קופצים עם נכסים מוגבלים

בידוד בין מקורות (CORS) והגנה מפני דליפות באתרים שונים במהלך אינטראקציה עם חלונות קופצים.

Arthur Hemery
Maud Nalpas
Maud Nalpas

ערך חדש זמין למדיניות פותחן מרובות מקורות (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.

משאבים