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

Maud Nalpas

בדף הזה מפורטות כמה שיטות מומלצות להגדרת 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:

ב-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.

איך רואים את המדיניות בנושא מקור ההפניה (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.