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

Maud Nalpas

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

סיכום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בטבלה הבאה אפשר לראות איך מדיניות ההפניה מגבילה את נתוני כתובות ה-URL שזמינים מכותרת ההפניה ומ-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.

איך רואים את מדיניות מקור ההפניה?

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

אפשר גם להשתמש בכלים למפתחים ב-Chrome, ב-Edge או ב-Firefox כדי לראות את מדיניות ההפניה שמשמשת לבקשה ספציפית. בזמן כתיבת המאמר הזה, Safari לא מציג את הכותרת Referrer-Policy, אבל כן מציג את הכותרת 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 פותרים את הבעיה הזו.
• משפר את הפרטיות: בבקשת CORS, 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 לבקשות cross-site. לפרטים

דוגמה: מדיניות ברמת הבקשה

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

מה עוד כדאי לקחת בחשבון?

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

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

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

הגנה על נתוני המשתמשים

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

הפניות נכנסות יכולות להשתנות {referer-can-change}

יש כמה מגבלות על השימוש בכתובת ה-referrer מבקשות נכנסות חוצות-מקורות:

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

חלופות ל-Referer

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

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

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

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

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

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

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

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

• בודקים אם אפשר לשנות את המערכות כך שיצפו ששולח הבקשה (לדוגמה, site-one.example) יגדיר באופן מפורש את המידע שאתם צריכים בסוג כלשהו של הגדרה.
  • יתרון: יותר מפורט, שומר יותר על הפרטיות של משתמשי site-one.example, עמיד יותר לאורך זמן.
  • חיסרון: יכול להיות שיהיה יותר עבודה מצדכם או מצד המשתמשים במערכת.
• בודקים אם האתר ששולח את הבקשות עשוי להסכים להגדיר מדיניות Referrer-Policy של 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 כחלופה. יכול להיות שהמידע הזה יספק לכם את מה שאתם צריכים לצורך ניפוי באגים, בצורה פשוטה יותר ובלי שתצטרכו לנתח את מקור התנועה.

תשלומים

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

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

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

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

סיכום

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

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

משאבים

• הסבר על המונחים 'אותו אתר' ו'אותו מקור'
• כותרת אבטחה חדשה: Referrer Policy (מדיניות מפנה) (2017)
• Referrer-Policy on MDN
• כותרת Referer: בעיות שקשורות לפרטיות ולאבטחה ב-MDN
• שינוי ב-Chrome: כוונה להטמעה ב-Blink
• שינוי ב-Chrome: כוונה להשיק את Blink
• שינוי ב-Chrome: כניסה לסטטוס
• שינוי ב-Chrome: 85 beta blogpost
• שרשור ב-GitHub בנושא חיתוך של כתובות מפנות: מה עושים דפדפנים שונים
• מפרט של מדיניות הגורם המפנה

תודה רבה לכל כותבי הביקורות על התרומה והמשוב – במיוחד ל-Kaustubha Govind,‏ David Van Cleve,‏ Mike West,‏ Sam Dutton,‏ Rowan Merewood,‏ Jxck ו-Kayce Basques.