Chrome משבית את האפשרות לשנות את document.domain

אם האתר שלכם מסתמך על הגדרת document.domain, עליכם לבצע את הפעולה.

Maud Nalpas

Eiji Kitamura

אזהרה: כפי שהודענו בינואר 2022, אנחנו מוציאים משימוש את ה-setter של document.domain החל מ-Chrome 115. אם האתר שלכם מסתמך על המדיניות המותנת של מקור נתונים זהה דרך document.domain, עליכם לפעול באופן מיידי. שימו לב: שימוש במגדיר document.domain‏ (document.domain = ...) לא יגרום להשלכת חריגה. היא רק תפסיק להיות בתוקף. אפשר להמשיך לקרוא כדי לקבל מידע נוסף על הסיבה לשינוי הזה, או לדלג אל קוד חלופי שאפשר להטמיע.

מה משתנה ומדוע?

החל מ-Chrome 115, לאתרים לא תהיה אפשרות להגדיר את document.domain: Chrome יהפוך את document.domain לבלתי ניתן לשינוי. כדי לתקשר בין מקורות שונים, צריך להשתמש בגישות חלופיות, כמו postMessage() או ChannelMessaging API.

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

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

למה להפוך את document.domain לבלתי ניתן לשינוי?

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

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

בפרטים: למה להפוך את document.domain לבלתי ניתן לשינוי?

איך document.domain משמש היום

באתרים רבים מגדירים את document.domain כדי לאפשר תקשורת בין דפים באותו אתר אבל ממקורות שונים.

לאתרים באותו אתר אבל ממקורות שונים יש את אותו eTLD+1 אבל תת-דומיינים שונים.

כך נעשה שימוש ב-document.domain עד עכשיו:

נניח שבדף ב-https://parent.example.com מוטמע דף iframe מ-https://video.example.com. לדפים האלה יש את אותו eTLD+1‏ (example.com) עם תתי-דומיינים שונים. כשהערך של document.domain בשני הדפים מוגדר כ-'example.com', הדפדפן מתייחס לשני המקוריים כאילו הם מאותו מקור.

מגדירים את document.domain עבור https://parent.example.com:

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

מגדירים את document.domain עבור https://video.example.com:

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

עכשיו אפשר ליצור מניפולציה של DOM בין מקורות ב-https://parent.example.com נגד https://video.example.com.

אתם יכולים להגדיר את document.domain באתרים כדי לאפשר למסמכים באותו אתר לתקשר בקלות רבה יותר. מכיוון שהשינוי הזה מרכך את מדיניות המקור הזהה, הדף ההורה יכול לגשת למסמך של ה-iframe ולעבור דרך עץ ה-DOM, ולהפך.

זוהי טכניקה נוחה, אבל היא גורמת לסיכון אבטחה.

בעיות אבטחה ב-document.domain

חששות אבטחה לגבי document.domain הובילו לשינוי במפרט, שבו מזהירים את המשתמשים להימנע משימוש בו.

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

למידע נוסף על ההשלכות של הגדרת document.domain על האבטחה, קראו את הדף Document.domain ב-MDN.

תאימות דפדפן

• במפרט HTML מצוין שצריך להסיר את התכונה.
• לדעת Mozilla, כדאי לפתח אב טיפוס להשבתת document.domain כברירת מחדל.
• WebKit ציינה שהיא תומכת באופן בינוני בהוצאה משימוש של ה-setter של document.domain.
• דיון עם ספקי דפדפנים אחרים
• בקשת משיכה של קבוצת העבודה של WHATWG / HTML (בהמתנה לניסיון)

איך אפשר לדעת אם האתר שלי מושפע?

אזהרה: שימו לב: החל מגרסה 115 של Chrome, שימוש במגדיר document.domain לא יגרום להשלכת חריגה, בהתאם למפרט. היא רק תפסיק להיות בתוקף.

אם האתר שלכם מושפע מהשינוי הזה, תופיע ב-Chrome אזהרה בחלונית הבעיות של DevTools. האזהרה הזו נוספה ב-2022. שימו לב לסמל הדגל הצהוב בפינה השמאלית העליונה של DevTools.

אפשר גם להריץ את האתר שלכם דרך בדיקת ממשקי ה-API שהוצאו משימוש ב-Lighthouse כדי למצוא את כל ממשקי ה-API שנקבע להסיר אותם מ-Chrome.

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

איך אפשר לראות את השינוי הזה בפעולה?

השינוי יושק בהדרגה, החל מ-Chrome 115. כדי לראות את השינוי הזה בפעולה גם אם הוא עדיין לא הופץ בדפדפן Chrome, אפשר להפעיל אותו באופן הבא:

1. פתיחה של chrome://flags/#origin-agent-cluster-default
2. בוחרים באפשרות הפעלה.
3. מפעילים מחדש את Chrome.

אילו חלופות אפשר להשתמש בהן?

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

שימוש ב-postMessage() או ב-Channel Messaging API במקום ב-document.domain

ברוב התרחישים לדוגמה, אפשר להחליף את document.domain ב-postMessage() בין מקורות או ב-Channel Messaging API.

בדוגמה הבאה:

1. https://parent.example.com מבקש מ-https://video.example.com בתוך iframe לבצע מניפולציה ב-DOM על ידי שליחת הודעה דרך postMessage().
2. https://video.example.com מבצע מניפולציות על DOM ברגע שהוא מקבל את ההודעה, ומעדכן את ההורה על ההצלחה.
3. https://parent.example.com מאשר את ההצלחה.

ב-https://parent.example.com:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

ב-https://video.example.com:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

כדאי לנסות את התכונה ולראות איך היא פועלת. אם יש לכם דרישות ספציפיות שלא יפעלו עם postMessage() או עם Channel Messaging API, תוכלו לעדכן אותנו ב-Twitter דרך @ChromiumDev או לפרסם שאלה ב-Stack Overflow עם תג document.domain.

כצאצא אחרון, שולחים את הכותרת Origin-Agent-Cluster: ?0

אם יש לכם סיבות טובות להמשיך להגדיר את document.domain, תוכלו לשלוח את כותרת התגובה Origin-Agent-Cluster: ?0 יחד עם מסמך היעד.

Origin-Agent-Cluster: ?0

הכותרת Origin-Agent-Cluster מורה לדפדפן אם המסמך צריך להיות מטופל על ידי אשכול הסוכנים לפי מקור או לא. מידע נוסף על Origin-Agent-Cluster זמין במאמר בקשה לבידוד ביצועים באמצעות הכותרת Origin-Agent-Cluster.

כששולחים את הכותרת הזו, אפשר להמשיך להגדיר את document.domain במסמך גם אחרי שהוא הופך לבלתי ניתן לשינוי כברירת מחדל.

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

הגדרת OriginAgentClusterDefaultEnabled למדיניות הארגון

לחלופין, האדמין יכול להגדיר את המדיניות של OriginAgentClusterDefaultEnabled ל-false כדי לאפשר הגדרה של document.domain כברירת מחדל במכונות Chrome בארגון. מידע נוסף זמין במאמר רשימת כללי המדיניות של Chrome Enterprise וניהול המדיניות | מסמכי עזרה.

משאבים

• Document.domain – ממשקי API של אינטרנט | MDN
• בידוד מקור והוצאה משימוש של document.domain
• הוצאה משימוש של document.domain. · Issue #564 · w3ctag/design-reviews

תודות

תמונה של Finan Akbar ב-Unsplash