Chrome ישבית את שינוי המסמך document.domain כדי להאט את מדיניות המקור הזהה

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

Eiji Kitamura

עדכונים

  • 30 במאי 2023: הודענו שההוצאה משימוש של ה-setter של document.domain תתבצע ב-Chrome 115.
  • 7 באפריל 2023: זיהינו בעיה לפני ששלחנו את השינוי הזה ב-Chrome 112. הגדרת ה-setter של document.domain שתבוטל כברירת מחדל מושעית כרגע, והשלב החדש של ההוצאה משימוש עדיין לא נקבע. מומלץ לחזור לפוסט הזה בבלוג או להירשם ל-blink-dev ולשרשור הזה.
  • 20 בינואר 2023: ציר זמן מעודכן – ה-setter של document.domain יוסר כברירת מחדל החל מ-Chrome 112. בנוסף, נוספה הערה לגבי מדיניות הארגון כדי לשלוט בהתנהגות של document.domain.
  • 25 ביולי 2022: ציר זמן מעודכן – הגדרת document.domain תוסר כברירת מחדל החל מגרסה 109 של Chrome.
  • 4 בפברואר 2022: עדכנו את ציר הזמן החדש – החל מגרסה 100 של Chrome, נציג אזהרה בחלונית הבעיות, ובגרסה 106 של Chrome נסיר את הגדרת document.domain כברירת מחדל.

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

ב-Chrome, לאתרים לא תהיה אפשרות להגדיר את document.domain. כדי לתקשר בין מקורות שונים, תצטרכו להשתמש בגישות חלופיות, כמו postMessage() או Channel Messaging API. אנחנו שואפים להשיק את השינוי הזה בגרסה 112 של Chrome, אבל זה תלוי בתשובה לכוונת השליחה.

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

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

באתרים רבים מגדירים את 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.

ב-Chrome מתכננים להפוך את document.domain לבלתי ניתן לשינוי בגרסה 112.

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

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

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

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

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

תקשורת חלופית בין מקורות שונים

בשלב הזה, יש שלוש אפשרויות להחלפת document.domain באתר שלכם.

שימוש ב-postMessage() או ב-Channel Messaging API

ברוב התרחישים לדוגמה, אפשר להחליף את 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 במסמך גם אחרי שהוא הופך לבלתי ניתן לשינוי כברירת מחדל.

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

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

תאימות דפדפן

משאבים

תודות

תמונה של Braydon Anderson ב-Unsplash