בדף הזה מפורטות כמה שיטות מומלצות להגדרת מדיניות מקור ההפניה באמצעות הגורם המפנה בבקשות נכנסות.
סיכום
- דליפת מידע לא צפויה ממקורות שונים פוגעת במשתמשי האינטרנט פרטיות. א' אפשר להיעזר במדיניות בנושא גורמים מפנים מגן.
- כדאי להגדיר מדיניות לגורם מפנה של
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
אם לא הוגדרה מדיניות לגורם מפנה, הדפדפן ישתמש במדיניות ברירת המחדל שלו.
דפדפן | ברירת המחדל של 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 ,
עם כמה הבדלים ספציפיים. צפייה
מניעת מעקב אחר מניעת מעקב לפרטים.
|
שיטות מומלצות להגדרת מדיניות לגורם מפנה
יש דרכים שונות להגדיר מדיניות לגורמים מפנים באתר:
- ככותרת HTTP
- בתוך HTML
- מ-JavaScript על על בסיס בקשה
אפשר להגדיר כללי מדיניות שונים לדפים, לבקשות או לרכיבים שונים.
כותרת ה-HTTP והמטא-רכיב הם שניהם ברמת הדף. סדר העדיפות של קביעת המדיניות בפועל של אלמנט כלשהו היא:
- מדיניות ברמת הרכיב
- מדיניות ברמת הדף
- ברירת המחדל של הדפדפן
דוגמה:
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.