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

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

סיכום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

היקף המדיניות	שם מדיניות	מפנה: אין נתונים	מקור ההפניה (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 כך שאין שדרוג לאחור.
• אם הבקשה היא Same-origin, המשמעות היא שהסכימה (HTTPS או HTTP) היא זהים, כך שאין שדרוג אבטחה לאחור.

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

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

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

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

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

• ככותרת 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 נשלח.

איזו מדיניות להגדיר עבור האתר שלך?

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

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

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

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

למה כדאי 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 מסוימות מכילות מידע מזהה או מידע אישי רגיש, להגדיר מדיניות הגנה.

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

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

הגנה על המשתמשים רוחב פס

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

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

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

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

חלופות ל-Referer

כדאי לשקול חלופות אם:

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

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

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

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

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

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

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

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

הגנה על ידי Cross-Site Request Forgery (CSRF)

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

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

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

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

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

תשלומים

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

סיכום

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

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

משאבים

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

תודה רבה על תרומתך ועל המשוב לכל כותבי הביקורות - בייחוד קאוטובה גובינד, David Van Cleve, Mike West, סאם דוטון, Rowan Merewood, Jxck ו-Kayce Basques.