מתכונים לקובצי cookie של SameSite

Rowan Merewood

אזהרה: הדפדפנים מגבילים את השימוש בקובצי cookie של צד שלישי. אם כבר הגדרתם את SameSite=None בקובצי ה-cookie, חובה לבצע פעולות נוספות. איך להתכונן לקראת הגבלות על קובצי cookie של צדדים שלישיים

הערה: הדף הזה הוא חלק מסדרה של שינויים במאפיינים של קובצי cookie SameSite, שכוללים:

• הסבר על קובצי cookie
• הסבר על קובצי cookie מסוג SameSite
• סכמה של אותו אתר

Chrome, Firefox, Edge ואחרים משנים את התנהגות ברירת המחדל שלהם בהתאם להצעת IETF, קובצי cookie טובים יותר באופן מצטבר, כך ש:

• קובצי cookie בלי המאפיין SameSite נחשבים ל-SameSite=Lax. כלומר, התנהגות ברירת המחדל היא להגביל את קובצי ה-cookie להקשרים של צד ראשון בלבד.
• בקובצי cookie לשימוש באתרים שונים חובה לציין SameSite=None; Secure כדי לאפשר הכללה בהקשר של צד שלישי.

אם עדיין לא עשית זאת, עליך לעדכן את המאפיינים של קובצי ה-cookie של צד שלישי כדי שהם לא ייחסמו בעתיד.

תמיכה בדפדפן

• 51
• ‏16
• 60
• 13

מקור

תרחישים לדוגמה עבור קובצי cookie של אתרים שונים או של צדדים שלישיים

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

תוכן בתוך <iframe>

תוכן מאתר אחר שמוצג ב-<iframe> מוצג בהקשר של צד שלישי. התרחישים לדוגמה הרגילים כוללים:

• תוכן מוטמע ששותף מאתרים אחרים, כמו סרטונים, מפות, דוגמאות קוד ופוסטים ברשתות חברתיות.
• ווידג'טים משירותים חיצוניים כמו תשלומים, יומנים, הזמנות ופיצ'רים להזמנות.
• ווידג'טים כמו לחצנים של רשתות חברתיות או שירותים למניעת הונאה שפחות ברורים <iframes>.

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

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

מכיוון שהאינטרנט הוא קומפוזבילי מטבעו, <iframes> משמש גם להטמעת תוכן שמוצג ברמה עליונה או בהקשר של צד ראשון. כל קובצי ה-cookie שהאתר שמוצג ב-iframe משתמש בהם נחשבים לקובצי cookie של צד שלישי. אם אתם יוצרים אתרים שאתם רוצים שאתרים אחרים יטמיעו, ואתם צריכים קובצי cookie כדי שהם יפעלו, עליכם גם לוודא שהם מסומנים לשימוש בין אתרים, או שניתן יהיה לחזור בחינניות בלעדיהם.

בקשות "לא בטוחות" באתרים שונים

"לא בטוח" אולי נשמע כאן מדאיג, אבל הוא מתייחס לכל בקשה שעשויה להיות מכוונת לשנות מצב. באינטרנט מדובר בעיקר בבקשות POST. קובצי cookie שמסומנים כ-SameSite=Lax נשלחים לניווט בטוח ברמה העליונה, למשל לחיצה על קישור כדי לעבור לאתר אחר. עם זאת, משהו כמו שליחה של <form> לאתר אחר באמצעות POST לא כולל קובצי cookie.

אם הבקשה הנכנסת משתמשת בשיטה 'בטוחה', הדף שולח קובצי cookie.

הדפוס הזה משמש לאתרים שיכולים להפנות את המשתמשים החוצה לשירות מרוחק כדי לבצע פעולה כלשהי לפני החזרה, לדוגמה, הפניה אוטומטית לספק זהויות של צד שלישי. לפני שהמשתמש עוזב את האתר, מוגדר קובץ cookie שמכיל אסימון לשימוש יחיד, על מנת שניתן יהיה לבדוק את האסימון בבקשה החוזרת, כדי לצמצם את ההתקפות של Cross Site Request Forgery (CSRF). אם הבקשה החוזרת עוברת דרך POST, צריך לסמן את קובצי ה-cookie כ-SameSite=None; Secure.

משאבים מרוחקים

כל משאב מרוחק בדף, כמו תגי <img> או תגי <script>, עשוי להסתמך על קובצי cookie שנשלחים עם בקשה. תרחישים נפוצים לדוגמה כוללים פיקסלים למעקב והתאמה אישית של תוכן.

הכלל הזה חל גם על בקשות שנשלחות מ-JavaScript באמצעות fetch או XMLHttpRequest. אם מתבצעת קריאה ל-fetch() באמצעות האפשרות credentials: 'include', סביר להניח שהבקשות האלה יכללו קובצי cookie. במקרה של XMLHttpRequest, קובצי cookie צפויים מסומנים בדרך כלל באמצעות ערך withCredentials של true. כדי לכלול בבקשות בין אתרים, קובצי ה-cookie האלה צריכים להיות מסומנים כראוי.

תוכן ב-WebView

WebView באפליקציה ספציפית לפלטפורמה מופעל על ידי דפדפן. מפתחים צריכים לבדוק אם ההגבלות או הבעיות שמשפיעות על האפליקציות שלהם חלות גם על רכיבי ה-WebView של האפליקציה.

Android גם מאפשר לאפליקציות הספציפיות לפלטפורמה שלו להגדיר קובצי cookie ישירות באמצעות ממשק ה-API של CookieManager. כמו בקובצי cookie שמוגדרים באמצעות כותרות או JavaScript, כדאי לכלול SameSite=None; Secure אם הם מיועדים לשימוש בכל האתרים.

איך ליישם את SameSite היום

מסמנים את קובצי ה-cookie שנחוצים רק בהקשר של צד ראשון בתור SameSite=Lax או SameSite=Strict, בהתאם לצרכים שלכם. אם לא תסמנו את קובצי ה-cookie האלה ותסתמכו על התנהגות ברירת המחדל של הדפדפן כדי לטפל בהם, הם עלולים להתנהג באופן לא עקבי בדפדפנים שונים ולהוביל לאזהרות במסוף לגבי כל קובץ cookie.

Set-Cookie: first_party_var=value; SameSite=Lax

חשוב לסמן את כל קובצי ה-cookie הנחוצים בהקשר של צד שלישי בתור SameSite=None; Secure. שני המאפיינים הם חובה. אם תציינו רק את None בלי Secure, קובץ ה-cookie יידחה. כדי להביא בחשבון את ההבדלים בהטמעות של הדפדפן, יכול להיות שתצטרכו להשתמש בחלק מאסטרטגיות הצמצום שמתוארות במאמר בנושא טיפול בלקוחות לא תואמים.

Set-Cookie: third_party_var=value; SameSite=None; Secure

טיפול בלקוחות לא תואמים

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

אחת הדרכים לעקוף את הבעיה היא להגדיר כל קובץ cookie בסגנון החדש ובסגנון הישן:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

דפדפנים שמטמיעים את ההתנהגות החדשה יותר מגדירים את קובץ ה-cookie עם הערך SameSite. דפדפנים שלא מטמיעים את ההתנהגות החדשה, מתעלמים מהערך הזה ומגדירים את קובץ ה-cookie 3pcookie-legacy. במהלך העיבוד של קובצי cookie כלולים, האתר צריך תחילה לבדוק את הנוכחות של קובץ cookie בסגנון החדש, ולאחר מכן לחזור לקובץ ה-cookie מהדור הקודם אם הוא לא מצליח למצוא קובץ חדש.

הדוגמה הבאה ממחישה איך לעשות זאת ב-Node.js באמצעות Express framework והתווכת שלו cookie-parser:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

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

לחלופין, אפשר לזהות את הלקוח באמצעות המחרוזת של סוכן המשתמש כשנשלחת כותרת Set-Cookie. כדאי לעיין ברשימת הלקוחות שאינם תואמים ולהשתמש בספרייה מתאימה לזיהוי סוכן משתמש בפלטפורמה שלכם, לדוגמה, הספרייה ua-parser-js ב-Node.js. בשיטה הזו תצטרכו לבצע רק שינוי אחד, אבל יכול להיות שסריקת סוכן משתמש לא תאתר את כל המשתמשים המושפעים.

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

תמיכה עבור SameSite=None בשפות, בספריות ובמסגרות

רוב השפות והספריות תומכות במאפיין SameSite לקובצי cookie. עם זאת, מכיוון שההוספה של SameSite=None עדיין יחסית עדכנית, ייתכן שתצטרכו לעקוף את ההתנהגות הרגילה בשלב זה. התנהגויות אלה מתועדות במאגר הדוגמאות של SameSite ב-GitHub.

קבלת עזרה

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

• העלאת בעיה במאגר של SameSite דוגמאות ב-GitHub.
• שואלים שאלה בתג 'samesite' ב-StackOverflow.
• אם נתקלתם בבעיות בהתנהגות של Chromium, דווחו על באג באתר המעקב אחר בעיות ב-Chromium.
• עקבו אחר ההתקדמות של Chrome בדף העדכונים של SameSite.