בדף הזה מפורטות כמה שיטות מומלצות להגדרת Referrer-Policy ולהשתמש בגורם המפנה בבקשות נכנסות.
סיכום
- דליפת מידע לא צפויה ממקורות שונים פוגעת בפרטיות המשתמשים באינטרנט. מדיניות מגינה לגורם מפנה יכולה לעזור.
- כדאי להגדיר מדיניות גורם מפנה עם הערך
strict-origin-when-cross-origin
. כך אפשר לשמור על רוב התועלת של המקור המפנה, תוך צמצום הסיכון לדליפת נתונים ממקורות שונים. - אין להשתמש בגורמים מפנים להגנה מפני זיוף בקשות בין אתרים (CSRF). במקום זאת, כדאי להשתמש באסימוני CSRF ובכותרות אחרות כשכבת אבטחה נוספת.
מדיניות 101 של גורם מפנה ומקור הפניה
בקשות HTTP יכולות לכלול כותרת Referer
אופציונלית, שמציינת את המקור או את כתובת ה-URL של דף האינטרנט שממנו נשלחה הבקשה. הכותרת Referrer-Policy
קובעת אילו נתונים יהיו זמינים בכותרת Referer
.
בדוגמה הבאה, הכותרת Referer
כוללת את כתובת ה-URL המלאה של הדף ב-site-one
שממנו נשלחה הבקשה.
הכותרת Referer
עשויה להופיע בסוגי בקשות שונים:
- בקשות ניווט, כשמשתמש לוחץ על קישור.
- בקשות של נכסי משנה, כשדפדפן מבקש תמונות, iframe, סקריפטים ומשאבים אחרים הדרושים לדף.
לניווטים ולתגי 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 המלאה: המקור, הנתיב ומחרוזת השאילתה
כללי מדיניות מסוימים פועלים באופן שונה בהתאם להקשר: בקשה ממקורות שונים או בקשה ממקור זהה, אם יעד הבקשה מאובטח כמו המקור או אם הוא מאובטח יותר או פחות. כך תוכלו להגביל את כמות המידע ששותף בין מקורות או למקורות פחות מאובטחים, תוך שמירה על עושר המידע של המקור להפניה באתר שלכם.
בטבלה הבאה מוסבר איך כללי המדיניות של גורם מפנה מגבילים את נתוני כתובת ה-URL שזמינים מהכותרת Referer ומ-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
.
איך רואים את המדיניות בנושא מקור ההפניה (referrer)?
securityheaders.com הוא כלי שימושי שבעזרתו אפשר לקבוע באיזו מדיניות משתמש אתר או דף ספציפי.
אפשר גם להשתמש בכלים למפתחים ב-Chrome, ב-Edge או ב-Firefox כדי לראות את מדיניות הגורם מפנה ששימשה לבקשה ספציפית. נכון למועד כתיבת המאמר, כותרת Referrer-Policy
לא מוצגת ב-Safari, אבל Referer
שנשלח כן מוצג.
איזו מדיניות כדאי להגדיר לאתר?
מומלץ מאוד להגדיר מדיניות לשיפור הפרטיות, כמו 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
פתרו את הבעיה הזו. - שיפור הפרטיות: בבקשה ממקורות שונים, כתובת ה-URL המלאה משותפת על ידי
no-referrer-when-downgrade
, דבר שעלול לגרום לבעיות בפרטיות.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
והם עמידים יותר בפני שינויים עתידיים. - חיסרון: יכול להיות שתצטרכו להשקיע יותר עבודה או שהמשתמשים במערכת יצטרכו להשקיע יותר עבודה.
- יתרון: מוצגים נתונים מפורטים יותר, יש הגנה טובה יותר על הפרטיות של משתמשי
- בודקים אם האתר שמפיק את הבקשות מוכן להגדיר את הערך
no-referrer-when-downgrade
ל-Referrer-Policy לכל רכיב או לכל בקשה.- חסרון: פוטנציאל של פחות שמירה על הפרטיות למשתמשי
site-one.example
, יכול להיות שלא נתמך בכל הדפדפנים.
- חסרון: פוטנציאל של פחות שמירה על הפרטיות למשתמשי
הגנה מפני זיוף בקשות בין אתרים (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
והוא תקין, תוכלו לעבור לשיטת אימות אחרת ואמינה יותר.
כדי לאמת תשלומים בצורה אמינה יותר, צריך לאפשר למגיש הבקשה לבצע גיבוב של הפרמטרים של הבקשה עם מפתח ייחודי. לאחר מכן, ספקי התשלומים יכולים לחשב את אותו גיבוב בצד שלכם ולקבל את הבקשה רק אם היא תואמת לחישוב שלכם.
מה קורה ל-Referer
כשאתר של מוֹכר ב-HTTP ללא מדיניות גורם מפנה מפנה אוטומטית לספק תשלומים ב-HTTPS?
Referer
לא מופיע בבקשה לספק התשלום ב-HTTPS, כי רוב הדפדפנים משתמשים ב-strict-origin-when-cross-origin
או ב-no-referrer-when-downgrade
כברירת מחדל כשלא מוגדרת מדיניות לאתר.
השינוי של Chrome למדיניות ברירת מחדל חדשה לא ישנה את ההתנהגות הזו.
סיכום
מדיניות מגינה של גורם מפנה היא דרך מצוינת לספק למשתמשים יותר פרטיות.
למידע נוסף על שיטות שונות להגנה על המשתמשים, אפשר לעיין באוסף המאמרים בנושא בטיחות ואבטחה
משאבים
- הסבר על 'באותו אתר' ו'באותו מקור'
- כותרת אבטחה חדשה: מדיניות הפניות (2017)
- Referrer-Policy ב-MDN
- כותרת Referer: בעיות פרטיות ואבטחה ב-MDN
- שינוי ב-Chrome: Blink מתכוונת להטמיע
- שינוי ב-Chrome: הבהוב של כוונה לשלוח
- שינוי ב-Chrome: הוספת סטטוס
- שינוי ב-Chrome: פוסט בבלוג של 85 בטא
- חיתוך שרשור ב-GitHub של מקור ההפניה (referrer): מה שדפדפנים שונים עושים
- מפרט של מדיניות הגורם המפנה
תודה רבה לכל הבודקים על התרומות והמשוב, במיוחד ל-Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck ו-Kayce Basques.