מדיניות ברירת מחדל חדשה לגורם מפנה ב-Chrome – strict-origin-when-cross-origin

Maud Nalpas
Maud Nalpas
X GitHub

לפני שמתחילים:

  • אם אתם לא בטוחים מה ההבדל בין 'אתר' לבין 'מקור', כדאי לעיין במאמר הסבר על המושגים 'אותו אתר' ו'אותו מקור'.
  • בכותרת Referer חסרה האות R, בגלל שגיאת כתיב במפרט המקורי. הכותרת Referrer-Policy והמאפיין referrer ב-JavaScript וב-DOM מאויתים בצורה נכונה.

סיכום

  • דפדפנים מתפתחים לכיוון מדיניות ברירת מחדל של גורם מפנה שמשפרת את הפרטיות, כדי לספק חלופה טובה כשלא מוגדרת מדיניות באתר.
  • ב-Chrome מתכננים להפעיל בהדרגה את strict-origin-when-cross-origin כמדיניות ברירת המחדל בגרסה 85. יכול להיות שהשינוי הזה ישפיע על תרחישי שימוש שמסתמכים על ערך הגורם המפנה ממקור אחר.
  • זו ברירת המחדל החדשה, אבל אתרים עדיין יכולים לבחור מדיניות לפי בחירתם.
  • כדי לנסות את השינוי ב-Chrome, מפעילים את התכונה הניסיונית בכתובת chrome://flags/#reduced-referrer-granularity. אפשר גם לצפות בהדגמה כדי לראות את השינוי בפועל.
  • בנוסף למדיניות בנושא מפנים, יכול להיות שהדרך שבה דפדפנים מתמודדים עם מפנים תשתנה, לכן חשוב לעקוב אחרי זה.

מה משתנה ולמה?

בקשות HTTP עשויות לכלול את הכותרת האופציונלית Referer, שמציינת את המקור או כתובת ה-URL של דף האינטרנט שממנו נשלחה הבקשה. הכותרת Referer-Policy מגדירה אילו נתונים יהיו זמינים בכותרת Referer, ובניווט ובמסגרות iframe בdocument.referrer של היעד.

המידע שיישלח בכותרת Referer בבקשה מהאתר שלכם תלוי בכותרת Referrer-Policy שהגדרתם.

תרשים: ה-referer נשלח בבקשה.
Referrer-Policy ו-Referer.

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

במקרה של ניווטים ו-iframes, אפשר לגשת לנתונים שמופיעים בכותרת Referer גם באמצעות JavaScript באמצעות document.referrer.

עד לאחרונה,no-referrer-when-downgrade הייתה מדיניות ברירת מחדל נפוצה בדפדפנים. אבל עכשיו הרבה דפדפנים נמצאים בשלב מסוים של מעבר להגדרות ברירת מחדל שמשפרות את הפרטיות.

‫Chrome מתכנן לשנות את מדיניות ברירת המחדל שלו מ-no-referrer-when-downgrade ל-strict-origin-when-cross-origin, החל מגרסה 85.

כלומר, אם לא מוגדרת מדיניות לאתר שלכם, Chrome ישתמש בערך strict-origin-when-cross-origin כברירת מחדל. שימו לב: אתם עדיין יכולים להגדיר מדיניות לבחירתכם. השינוי הזה ישפיע רק על אתרים שלא הוגדרה להם מדיניות.

מה המשמעות של השינוי הזה?

‫strict-origin-when-cross-origin מציע יותר פרטיות. במדיניות הזו, רק המקור נשלח בכותרת Referer של בקשות ממקורות שונים.

כך נמנעות דליפות של נתונים פרטיים שאולי אפשר לגשת אליהם מחלקים אחרים של כתובת ה-URL המלאה, כמו הנתיב ומחרוזת השאילתה.

תרשים: הגורם המפנה נשלח בהתאם למדיניות, עבור בקשה ממקורות שונים.
הגורם המפנה נשלח (וגם document.referrer) עבור בקשה ממקורות שונים, בהתאם למדיניות.

לדוגמה:

בקשת CORS שנשלחה מכתובת האתר https://site-one.example/stuff/detail?tag=red אל https://site-two.example/…‎:

  • עם no-referrer-when-downgrade: Referer: https://site-one.example/stuff/detail?tag=red.
  • עם strict-origin-when-cross-origin: Referer: https://site-one.example/.

מה לא ישתנה?

  • בדומה ל-no-referrer-when-downgrade, ‏ strict-origin-when-cross-origin הוא מאובטח: לא מופיע גורם מפנה (כותרת Referer ו-document.referrer) כשהבקשה נשלחת ממקור HTTPS (מאובטח) למקור HTTP (לא מאובטח). כך, אם האתר שלכם משתמש ב-HTTPS (אם לא, כדאי לתת לזה עדיפות), כתובות ה-URL של האתר לא ייחשפו בבקשות שאינן HTTPS – כי כל אחד ברשת יכול לראות אותן, ולכן המשתמשים שלכם יהיו חשופים למתקפות מסוג'אדם באמצע'.
  • באותו מקור, ערך הכותרת Referer הוא כתובת ה-URL המלאה.

לדוגמה: בקשה מאותו מקור, שנשלחה מכתובת האתר https://site-one.example/stuff/detail?tag=red אל https://site-one.example/…‎:

  • עם strict-origin-when-cross-origin: Referer: https://site-one.example/stuff/detail?tag=red

מה ההשפעה?

על סמך דיונים עם דפדפנים אחרים וניסויים שבוצעו ב-Chrome 84, ההשפעה על המשתמשים צפויה להיות מוגבלת.

סביר להניח שרישום בצד השרת או ניתוח נתונים שמסתמך על כתובת ה-URL המלאה של הגורם המפנה יושפעו מהפחתת רמת הפירוט של המידע הזה.

מה צריך לעשות?

ב-Chrome מתכננים להתחיל להשיק את מדיניות ברירת המחדל החדשה לגבי הגורם המפנה בגרסה 85 (יולי 2020 לגרסת בטא, אוגוסט 2020 לגרסה יציבה). אפשר לראות את הסטטוס בכניסה לסטטוס של Chrome.

הסבר על השינוי וזיהוי שלו

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

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

בודקים את השינוי ומנסים להבין אם הוא ישפיע על האתר

אתם יכולים לנסות את השינוי כבר עכשיו החל מגרסה 81 של Chrome: נכנסים אל chrome://flags/#reduced-referrer-granularity ב-Chrome ומפעילים את התכונה הניסיונית. אם הדגל הזה מופעל, כל האתרים ללא מדיניות ישתמשו בברירת המחדל החדשה של strict-origin-when-cross-origin.

צילום מסך של Chrome: איך מפעילים את הדגל chrome://flags/#reduced-referrer-granularity.
הפעלת הדגל.

עכשיו אפשר לבדוק את ההתנהגות של האתר והקצה העורפי.

דרך נוספת לזהות את ההשפעה היא לבדוק אם בבסיס הקוד של האתר נעשה שימוש בכתובת הדף המפנה – באמצעות הכותרת Referer של בקשות נכנסות בשרת, או באמצעות document.referrer ב-JavaScript.

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

אם זה משפיע על האתר שלכם, כדאי לשקול חלופות

אם אתם משתמשים בפרמטר referrer כדי לגשת לנתיב המלא או למחרוזת השאילתה של בקשות לאתר שלכם, יש לכם כמה אפשרויות:

  • אפשר להשתמש בטכניקות חלופיות ובכותרות כמו Origin ו-Sec-fetch-Site להגנה מפני CSRF, לרישום ביומן ולתרחישי שימוש אחרים. כדאי לעיין במאמר Referer ו-Referrer-Policy: שיטות מומלצות.
  • אם יש צורך בכך, אפשר להגיע להסכמה עם שותפים לגבי מדיניות ספציפית, בתנאי שהיא שקופה למשתמשים. שליטה בגישה – כשאתרים משתמשים בגורם המפנה כדי להעניק גישה ספציפית למשאבים שלהם למקורות אחרים – יכולה להיות דוגמה למקרה כזה, אם כי בעקבות השינוי ב-Chrome, המקור עדיין ישותף בכותרת Referer (וב-document.referrer).

שימו לב שרוב הדפדפנים נעים בכיוון דומה בכל הנוגע לכתובת הדף המפנה (ראו את ברירות המחדל של הדפדפנים וההתפתחויות שלהם במאמר Referer ו-Referrer-Policy: שיטות מומלצות).

הטמעה של מדיניות ברורה לשיפור הפרטיות באתר

מה צריך לשלוח בבקשות שמקורן באתר שלך, כלומר איזו מדיניות צריך להגדיר באתר?Referer

גם אחרי השינוי ב-Chrome, מומלץ להגדיר כבר עכשיו מדיניות מפורשת לשיפור הפרטיות, כמו strict-origin-when-cross-origin או מדיניות מחמירה יותר.

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

במאמר Referrer ו-Referrer-Policy: שיטות מומלצות מפורטות הוראות להגדרת מדיניות.

מידע על Chrome Enterprise

מדיניות Chrome Enterprise‏ ForceLegacyDefaultReferrerPolicy זמינה לאדמינים בתחום ה-IT שרוצים להחיל את מדיניות ברירת המחדל הקודמת של הגורם המפנה no-referrer-when-downgrade בסביבות ארגוניות. כך ארגונים יכולים לקבל זמן נוסף לבדיקה ולעדכון של האפליקציות שלהם.

המדיניות הזו תוסר ב-Chrome 88.

שליחת משוב

רוצה לשלוח משוב או לדווח על משהו? אפשר לשתף משוב על הכוונה של Chrome להשיק, או לצייץ שאלות אל @maudnals.

תודה רבה על התרומה והמשוב לכל כותבי הביקורות – במיוחד ל-Kaustubha Govind,‏ David Van Cleve, ‏ Mike West, ‏ Sam Dutton, ‏ Rowan Merewood, ‏ Jxck ו-Kayce Basques.

משאבים