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

Maud Nalpas

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

סיכום

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

הערה:

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

הסבר על Referer ו-Referrer-Policy

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

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

בקשת HTTP עם כותרת Referer.

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

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

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

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

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

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

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

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

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

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

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

דוגמאות לנתוני Referer.

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

בטבלה הבאה מוצג איך כללי מדיניות של מקורות הפניה מגבילים את נתוני כתובות ה-URL שזמינים מהכותרת Referer ומהמאפיין 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
	same-origin	בקשה ממקור חיצוני		בקשה מסוג same-origin
התמקדות בפרטיות ובאבטחה	strict-origin-when-cross-origin	בקשה מ-HTTPS ל-HTTP	בקשה ממקורות שונים מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP	בקשה מסוג same-origin

ב-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, למשתמשים ב-Strict Tracking Protection ובגלישה פרטית, המערכת מתעלמת ממדיניות ההפניה הפחות מגבילה no-referrer-when-downgrade, origin-when-cross-origin ו-unsafe-url בבקשות בין אתרים, כלומר ההפניה תמיד נחתכת בבקשות בין אתרים, ללא קשר למדיניות של האתר.
Edge	ערך ברירת המחדל הוא strict-origin-when-cross-origin.
Safari	ברירת המחדל דומה ל-strict-origin-when-cross-origin, עם כמה הבדלים ספציפיים. פרטים נוספים זמינים במאמר מניעת מעקב אחרי מניעת מעקב.

שיטות מומלצות להגדרת מדיניות הפניות (referrer)

המטרה: להגדיר באופן מפורש מדיניות לשיפור הפרטיות, כמו 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 מאשר בעבר.
• דפדפנים משתמשים יותר ויותר ב-Referrer-Policy strict-origin-when-cross-origin כברירת מחדל. זה אומר שאם לאתר השולח אין מדיניות מוגדרת, יכול להיות שעכשיו תקבלו רק את המקור, במקום כתובת URL מלאה של גורם מפנה, בבקשות נכנסות ממקורות שונים.
• יכול להיות שהדפדפנים ישנו את האופן שבו הם מנהלים את Referer. לדוגמה, יכול להיות שמפתחי דפדפנים מסוימים יחליטו תמיד לחתוך את המפנים למקורות בבקשות למשאבי משנה ממקורות שונים, כדי להגן על פרטיות המשתמשים.
• יכול להיות שהכותרת Referer (וגם document.referrer) תכיל יותר נתונים ממה שאתם צריכים. לדוגמה, יכול להיות שהיא תכלול כתובת URL מלאה, גם אם אתם רק רוצים לדעת אם הבקשה היא ממקורות שונים.

חלופות ל-Referer

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

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

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

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

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

אם אתם צריכים רכיבים אחרים של כתובת ה-URL (נתיב, פרמטרים של שאילתה וכו')

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

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

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

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

גורם ששולח בקשה תמיד יכול להחליט לא לשלוח את המפנה על ידי הגדרת מדיניות 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 הצליחה, אפשר לעבור לשיטת אימות אחרת ואמינה יותר.

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

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

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

הערה: אם האתר שלכם משתמש ב-HTTP, עברו ל-HTTPS.

סיכום

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

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

משאבים

• הסבר על "אותו אתר" ו "אותו מקור"
• כותרת אבטחה חדשה: מדיניות הפניה (2017)
• Referrer-Policy ב-MDN
• כותרת מפנה: בעיות פרטיות ואבטחה ב-MDN
• שינוי ב-Chrome: כוונה להטמיע את Blink
• שינוי ב-Chrome: כוונה להשיק את Blink
• שינוי ב-Chrome: רישום בסטטוס
• שינוי ב-Chrome: פוסט בבלוג על גרסת בטא 85
• שרשור ב-GitHub בנושא קיצוץ מפנים: מה עושים דפדפנים שונים
• מפרט של Referrer-Policy

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