שיטות מומלצות למדיניות בנושא הפניות וגורמים מפנים

Maud Nalpas

בדף הזה מפורטות כמה שיטות מומלצות להגדרת מדיניות הגורם המפנה ולשימוש בגורם המפנה בבקשות נכנסות.

סיכום

• דליפה לא צפויה של מידע ממקורות שונים פוגעת בפרטיות של משתמשי האינטרנט. מדיניות מגינה לגורם מפנה יכולה לעזור.
• כדאי להגדיר מדיניות לגורם מפנה של strict-origin-when-cross-origin. הוא משמר את רוב השימושיות של הגורם המפנה, ומצמצם את הסיכון להדלפת נתונים ממקורות שונים.
• אין להשתמש בגורמים מפנים לצורך הגנה מפני זיוף בקשות באתרים שונים (CSRF). במקום זאת, כדאי להשתמש באסימוני CSRF ובכותרות אחרות כשכבת אבטחה נוספת.

הערה:

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

101 מדיניות של גורם מפנה וגורם מפנה

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

בדוגמה הבאה, הכותרת Referer כוללת את כתובת ה-URL המלאה של הדף ב-site-one שממנו נשלחה הבקשה.

בקשת HTTP עם כותרת של גורם מפנה.

הכותרת Referer עשויה להופיע בסוגים שונים של בקשות:

• בקשות ניווט, כשמשתמש לוחץ על קישור.
• בקשות למשאבי משנה, כשדפדפן מבקש תמונות, iframes, סקריפטים ומשאבים אחרים שנדרשים לדף.

לניווטים ולמסגרות iframe, אפשר גם לגשת לנתונים האלה באמצעות JavaScript באמצעות document.referrer.

אפשר ללמוד הרבה מהערכים של Referer. לדוגמה, שירות ניתוח נתונים עשוי להשתמש בהם כדי לקבוע ש-50% מהמבקרים ב-site-two.example הגיעו מ-social-network.example. אבל כתובת ה-URL המלאה, כולל הנתיב ומחרוזת השאילתה, נשלחת ב-Referer בכל המקורות, עלולה לסכן את פרטיות המשתמשים וליצור סיכוני אבטחה:

שימוש בכתובת ה-URL המלאה יכול להשפיע על הפרטיות ועל האבטחה של המשתמשים.

כתובות URL מס' 1 עד מס' 5 מכילות מידע פרטי, ולפעמים מידע רגיש או מידע מזהה. הדלפה שקטה של מידע כזה ממקורות שונים עלולה לפגוע בפרטיות של משתמשי האינטרנט.

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

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

אילו כללי מדיניות זמינים ובמה הם שונים?

אפשר לבחור אחד מתוך שמונה כללי מדיניות. בהתאם למדיניות, הנתונים שזמינים מהכותרת Referer (וגם document.referrer) יכולים להיות:

• אין נתונים (אין כותרת Referer)
• רק הערך origin
• כתובת ה-URL המלאה: מקור, נתיב ומחרוזת שאילתה

דוגמאות לנתוני הפניה.

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

הטבלה הבאה מראה איך המדיניות לגורם מפנה מגבילה את הנתונים של כתובות ה-URL הזמינים בכותרת הגורם המפנה וב-document.referrer:

היקף המדיניות	שם מדיניות	מפנה: אין נתונים	מקור הפניה: מקור בלבד	מפנה: כתובת URL מלאה
לא כולל את ההקשר של הבקשה	no-referrer	בדיקה
	origin		בדיקה
	unsafe-url			בדיקה
ממוקד באבטחה	strict-origin	בקשה מ-HTTPS ל-HTTP	בקשה מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP
	no-referrer-when-downgrade	בקשה מ-HTTPS ל-HTTP		בקשה מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP
ממוקד בפרטיות	origin-when-cross-origin		בקשה ממקורות שונים	בקשה מאותו מקור
	same-origin	בקשה ממקורות שונים		בקשה מאותו מקור
דגש על פרטיות ואבטחה	strict-origin-when-cross-origin	בקשה מ-HTTPS ל-HTTP	בקשה ממקורות שונים מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP	בקשה מאותו מקור

MDN מספק רשימה מלאה של כללי מדיניות ודוגמאות להתנהגות.

הנה כמה דברים שכדאי לדעת בעת הגדרת מדיניות לגורם מפנה:

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

מדיניות ברירת מחדל לגורם מפנה בדפדפנים

נכון לאוקטובר 2021

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

דפדפן	ברירת מחדל של Referrer-Policy / התנהגות
Chrome	ערך ברירת המחדל הוא strict-origin-when-cross-origin.
Firefox	ערך ברירת המחדל הוא strict-origin-when-cross-origin. החל מגרסה 93, עבור משתמשים עם הגנה מחמירה של מעקב וגלישה פרטית, המערכת מתעלמת מכללי המדיניות הפחות מגבילים לגורם מפנה no-referrer-when-downgrade, origin-when-cross-origin ו-unsafe-url עבור בקשות בין אתרים. כלומר, הגורם המפנה תמיד ייחתך עבור בקשות בין אתרים, בלי קשר למדיניות של האתר.
Edge	ערך ברירת המחדל הוא strict-origin-when-cross-origin.
Safari	ברירת המחדל דומה ל-strict-origin-when-cross-origin, עם כמה הבדלים ספציפיים. לפרטים נוספים, אפשר לעיין במאמר מניעת מעקב אחר מניעת מעקב.

שיטות מומלצות להגדרת המדיניות לגורם מפנה

מטרה: הגדרה מפורשת של מדיניות לשיפור הפרטיות, כגון strict-origin-when-cross-origin(או מחמירה יותר).

יש דרכים שונות להגדיר באתר שלכם מדיניות לגורם מפנה:

• ככותרת HTTP
• ב-HTML
• מ-JavaScript על בסיס בקשה

אפשר להגדיר כללי מדיניות שונים לדפים, לבקשות או לרכיבים שונים.

כותרת ה-HTTP והמטא-רכיב הם שניהם ברמת הדף. סדר העדיפות לקביעת המדיניות האפקטיבית של אלמנט הוא:

1. מדיניות ברמת הרכיב
2. מדיניות ברמת הדף
3. ברירת המחדל של הדפדפן

דוגמה:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

הבקשה לתמונה היא באמצעות מדיניות no-referrer-when-downgrade, וכל שאר הבקשות למשאבי משנה מהדף הזה עומדות בדרישות המדיניות strict-origin-when-cross-origin.

איך להציג את המדיניות לגורם מפנה?

בעזרת securityheaders.com ניתן לקבוע באיזו מדיניות משתמשים באתר או בדף ספציפיים.

אפשר גם להשתמש בכלים למפתחים ב-Chrome, ב-Edge וב-Firefox כדי לראות את המדיניות לגורם מפנה, של בקשה ספציפית. נכון לעכשיו, Safari לא מציג את הכותרת Referrer-Policy אבל כן מציג את Referer שנשלח.

החלונית רשת של כלי הפיתוח ל-Chrome, שנבחרה בה בקשה.

איזו מדיניות כדאי להגדיר לאתר?

אנחנו ממליצים מאוד להגדיר מדיניות לשיפור הפרטיות, כמו strict-origin-when-cross-origin (או מחמירה יותר).

למה "באופן מפורש"?

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

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

למה strict-origin-when-cross-origin (או מחמירה יותר)?

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

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

כלומר, באופן כללי strict-origin-when-cross-origin הוא בחירה הגיונית.

דוגמה: הגדרת מדיניות strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

או בצד השרת, למשל ב-Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

מה קורה אם strict-origin-when-cross-origin (או המחמיר יותר) לא מתאים לכל התרחישים לדוגמה?

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

דוגמה: מדיניות ברמת הרכיב

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit עשוי להגביל את document.referrer או את הכותרת Referer לבקשות של אתרים שונים. לפרטים.

דוגמה: מדיניות ברמת הבקשה

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

מה עוד כדאי לשקול?

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

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

שיטות מומלצות לטיפול בבקשות נכנסות

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

הגנה על נתוני המשתמשים

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

גורמים מפנים נכנסים יכולים לשנות {referer-can-change}

לשימוש בגורם המפנה מבקשות נכנסות ממקורות שונים יש מספר מגבלות:

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

יש חלופות ל-Referer

יכול להיות שתצטרכו לשקול חלופות במקרים הבאים:

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

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

אם צריך רק את המקור

• אם משתמשים בגורם המפנה בסקריפט שיש לו גישה ברמה העליונה לדף, window.location.origin הוא אפשרות חלופית.
• אם הן זמינות, כותרות כמו Origin ו-Sec-Fetch-Site מספקות את Origin או מתארות אם הבקשה היא ממקורות שונים, ויכול להיות שזה בדיוק מה שצריך.

אם דרושים רכיבים נוספים של כתובת ה-URL (נתיב, פרמטרים של שאילתה...)

• פרמטרים של בקשה יכולים לטפל בתרחיש לדוגמה, וכך לחסוך את העבודה בניתוח הגורם המפנה.
• אם משתמשים בגורם המפנה בסקריפט שיש לו גישה ברמה העליונה לדף, window.location.pathname עשוי לשמש כחלופה. מחלצים רק את קטע הנתיב של כתובת ה-URL ומעבירים אותו כארגומנט, כך שמידע שעשוי להיות רגיש בפרמטרים של כתובת האתר לא יועבר.

אם לא ניתן להשתמש בחלופות האלה:

• בדקו אם אפשר לשנות את המערכות כך שיצפו משדר הבקשות (לדוגמה site-one.example) יגדיר במפורש את המידע שדרוש לכם בסוג כלשהו של הגדרה.
  • יתרונות: יותר מפורש, יותר שמירה על הפרטיות עבור משתמשי site-one.example, יותר ביטחון לעתיד.
  • חסרונות: ייתכן שיותר עבודה בצד שלכם או עבור משתמשי המערכת שלכם.
• עליכם לבדוק אם האתר ששולח את הבקשות עשוי להסכים להגדיר מדיניות מפנה של no-referrer-when-downgrade לכל רכיב או לפי בקשה.
  • חסרונות: אפשרות השמירה על הפרטיות עשויה להיות נמוכה יותר אצל משתמשי site-one.example, וייתכן שלא תהיה תמיכה בכל הדפדפנים.

הגנה על פני זיוף בקשות באתרים שונים (CSRF)

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

שימוש באסימוני CSRF כהגנה הראשית. כדי להוסיף שכבת הגנה, כדאי להשתמש ב-SameSite, ובמקום ב-Referer להשתמש בכותרות כמו Origin (שזמינות בבקשות POST ו-CORS) ו-Sec-Fetch-Site אם היא זמינה.

רישום ביומן וניפוי באגים

חשוב להגן על מידע אישי או רגיש של המשתמשים, שעשוי להיות ב-Referer.

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

תשלומים

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

למשל:

• המשתמש לוחץ על לחצן קנייה ב-online-shop.example/cart/checkout.
• online-shop.example מפנה אוטומטית לכתובת payment-provider.example כדי לנהל את העסקה.
• payment-provider.example בודק את Referer של הבקשה הזו מול רשימה של ערכי Referer מותרים שהוגדרו על ידי המוכרים. אם היא לא תואמת לאף רשומה ברשימה, payment-provider.example ידחה את הבקשה. אם היא תואמת, המשתמש יכול להמשיך לעסקה.

שיטות מומלצות לבדיקות אבטחה של תזרים תשלומים

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

בדיקה של Referer עשויה לעזור לספקי תשלומים לתפוס תוקפים תמימים שלא הגדירו מדיניות no-referrer. אם משתמשים בReferer כבדיקה ראשונה:

• לא תצפה שה-Referer יהיה תמיד קיים. אם הוא קיים, צריך לבדוק אותו רק מול הנתונים המינימליים שהוא יכול לכלול, שהוא המקור.
  • כשמגדירים את רשימת הערכים המותרים של Referer, חשוב לכלול רק את המקור ולא את הנתיב.
  • לדוגמה, ערכי Referer המותרים עבור online-shop.example צריכים להיות online-shop.example, ולא online-shop.example/cart/checkout. כשמצפים לערך Referer בכלל או לערך Referer שהוא רק מקור האתר המבקש, אפשר למנוע שגיאות שעשויות לנבוע מהנחות לגבי Referrer-Policy של המוכר.
• אם השדה Referer חסר, או אם הוא קיים ובדיקת המקור הבסיסית של Referer בוצעה בהצלחה, אפשר לעבור לשיטת אימות אחרת ואמינה יותר.

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

מה קורה לכתובת Referer כשאתר של מוכר HTTP ללא מדיניות לגורם מפנה מפנה לספק תשלום מסוג HTTPS?

לא מופיע Referer בבקשה לספק התשלום ב-HTTPS, כי רוב הדפדפנים משתמשים ב-strict-origin-when-cross-origin או no-referrer-when-downgrade כברירת מחדל כשלאתר לא הוגדרה מדיניות. המעבר של Chrome למדיניות ברירת מחדל חדשה לא ישנה את ההתנהגות הזו.

הערה: אם באתר נעשה שימוש ב-HTTP, צריך לעבור ל-HTTPS.

סיכום

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

למידע נוסף על שיטות שונות להגנה על המשתמשים, כדאי לעיין באוסף בטוחים ומאובטחים

משאבים

• הסבר על "same-site" ו-"same-origin"
• כותרת אבטחה חדשה: מדיניות מפנה (2017)
• מדיניות של גורמים מפנים ב-MDN
• כותרת הגורם המפנה: חששות בנוגע לפרטיות ולאבטחה ב-MDN
• שינוי ב-Chrome: כוונה להבהב כדי להטמיע
• שינוי ב-Chrome: הכוונה בהבהוב
• שינוי ב-Chrome: רשומת סטטוס
• שינוי ב-Chrome: פוסט בבלוג של גרסת בטא 85
• חיתוך של שרשור GitHub באמצעות הגורם המפנה: מה דפדפנים שונים עושים
• מפרט המדיניות של הגורם המפנה

תודה רבה על התוכן והמשוב לכל הבודקים – במיוחד קאסטובהה גובינד, דיוויד ואן קליב, מייק ווסט, סאם דוטון, רוואן מרווד, ג'קסק וקייס באסק.