סכמה של אותו אתר

ההגדרה של 'אותו אתר' משתנה ותכלול את סכמת כתובת ה-URL, כך שקישורים בין גרסאות HTTP ו-HTTPS של אתר נחשבים עכשיו כבקשות בין אתרים. כדאי לשדרג ל-HTTPS כברירת מחדל כדי למנוע בעיות במידת האפשר. אפשר גם להמשיך לקרוא כדי לקבל פרטים לגבי ערכי המאפיינים של SameSite שדרושים כברירת מחדל.

סטיבן בינגלר
סטיבן בינגלר
GitHub
רואן מרווד

Schemeful Same-Site: שינוי ההגדרה של אתר (אתר) רק מהדומיין שניתן לרשום לסכימה + הדומיין לרישום. פרטים ודוגמאות נוספים מופיעים במאמר הסבר על "אותו אתר" ו"אותו מקור".

החדשות הטובות הן: אם האתר כבר שודרג במלואו ל-HTTPS, אין צורך לדאוג. שום דבר לא ישתנה אצלכם.

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

אפשר להפעיל את השינויים האלה לבדיקה גם ב-Chrome וגם ב-Firefox.

  • החל מ-Chrome 86, מפעילים את about://flags/#schemeful-same-site. עקוב אחר ההתקדמות בדף הסטטוס של Chrome.
  • החל מ-Firefox 79, מגדירים את network.cookie.sameSite.schemeful ל-true דרך about:config. עקבו אחר ההתקדמות באמצעות הבעיה ב-Bugzilla.

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

תרחישים נפוצים בכמה סכימות

מעבר בין גרסאות של אתר עם סכמות שונות (למשל, קישור מהדומיין http://site.example אל https://site.example) היה מאפשר בעבר שליחה של SameSite=Strict קובצי cookie. עכשיו מדובר במעבר בין אתרים, ופירוש הדבר הוא ש-SameSite=Strict קובצי cookie ייחסמו.

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

משאבי המשנה בטעינה

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

דוגמאות למשאבי משנה כוללות תמונות, מסגרות iframe ובקשות לרשת, שבוצעו באמצעות XHR או Fetch.

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

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

משאב משנה חוצה-סכמות שנובע ממשאב מגרסת ה-HTTPS המאובטחת של האתר שנכללת בגרסת ה-HTTP הלא מאובטחת. SameSite=Strict ו-SameSite=Lax חסומים, ו-SameSite=None; קובצי Cookie מאובטחים מותרים.
דף HTTP שכולל משאב משנה של סכמות שונות דרך HTTPS.
HTTP ← HTTPS HTTPS ← HTTP
SameSite=Strict ⛔ חסום ⛔ חסום
SameSite=Lax ⛔ חסום ⛔ חסום
SameSite=None;Secure ✓ מותר ⛔ חסום

פרסום טופס

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

בדומה למשאבי משנה, במקרה שהבקשה עוברת מדומיין מאובטח, כמו HTTPS, לאתר לא מאובטח (כמו HTTP), כל קובצי ה-Cookie ייחסמו בבקשות האלה כי קובצי Cookie של צד שלישי או של כמה אתרים דורשים Secure.

שליחת טופס חוצה-סכמות שנובעת מטופס בגרסת HTTP לא מאובטחת של האתר שנשלח לגרסת ה-HTTPS המאובטחת. SameSite=Strict ו-SameSite=Lax חסומים, ו-SameSite=None; קובצי Cookie מאובטחים מותרים.
שליחת טופס בכמה סכימות מ-HTTP ל-HTTPS.
HTTP ← HTTPS HTTPS ← HTTP
SameSite=Strict ⛔ חסום ⛔ חסום
SameSite=Lax ⛔ חסום ⛔ חסום
SameSite=None;Secure ✓ מותר ⛔ חסום

איך אפשר לבדוק את האתר?

ניתן להשתמש בכלים ובהעברת ההודעות למפתחים ב-Chrome וב-Firefox.

החל מגרסה 86 של Chrome, הכרטיסייה Issue (בעיות) בכלי הפיתוח תכלול בעיות באותו אתר הסכמות. יכול להיות שהבעיות הבאות יודגשו באתר שלכם.

בעיות בניווט:

  • "העברה מלאה ל-HTTPS כדי להמשיך לשלוח קובצי cookie בבקשות מאותו אתר" - אזהרה על כך שקובץ ה-cookie ייחסם בגרסה עתידית של Chrome.
  • "העברה מלאה ל-HTTPS כדי שקובצי cookie יישלחו בבקשות מאותו אתר" – אזהרה על כך שקובץ ה-cookie נחסם.

בעיות בטעינה של משאבי משנה:

  • "העברה מלאה ל-HTTPS כדי להמשיך שליחת קובצי cookie למשאבי משנה באותו אתר" או "העברה מלאה ל-HTTPS כדי להמשיך לאפשר הגדרה של קובצי cookie באמצעות משאבי משנה באותו אתר" – אזהרות על כך שקובץ ה-cookie ייחסם בגרסה עתידית של Chrome.
  • "העברה מלאה ל-HTTPS כדי שקובצי cookie יישלחו למשאבי משנה באותו אתר" או "העברה מלאה ל-HTTPS כדי לאפשר הגדרה של קובצי cookie על ידי משאבי משנה באותו אתר" – אזהרה על כך שקובץ ה-cookie נחסם. האזהרה האחרונה יכולה להופיע גם כשמפרסמים טופס.

פרטים נוספים זמינים בטיפים לבדיקה ולניפוי באגים עבור סכמה באותו אתר.

החל מ-Firefox 79, כאשר network.cookie.sameSite.schemeful מוגדר ל-true דרך about:config, המסוף יציג הודעה לגבי בעיות סכמה באותו אתר. יכול להיות שתראו באתר את הפרטים הבאים:

  • "בקרוב המערכת תתייחס לקובץ ה-cookie cookie_name בתור קובצי cookie באתרים שונים מול http://site.example/, כי הסכימה לא תואמת."
  • "קובץ ה-cookie cookie_name טופל כחיוב מאתרים שונים מול http://site.example/ כי הסכימה לא תואמת."

שאלות נפוצות

האתר שלי כבר זמין באופן מלא ב-HTTPS. למה אני רואה בעיות בכלי הפיתוח של הדפדפן?

יכול להיות שחלק מהקישורים ומשאבי המשנה מפנים לכתובות URL לא מאובטחות.

אחת מהדרכים לפתור את הבעיה היא להשתמש ב-HTTP Strict-Transport-Security (HSTS) ובהוראה includeSubDomain. בעזרת HSTS + includeSubDomain, גם אם אחד הדפים כולל בטעות קישור לא מאובטח, הדפדפן ישתמש באופן אוטומטי בגרסה המאובטחת במקום זאת.

מה קורה אם אין אפשרות לשדרג ל-HTTPS?

אנחנו ממליצים מאוד לשדרג את האתר ל-HTTPS כדי להגן על המשתמשים, אבל אם אין לכם אפשרות לעשות זאת בעצמכם, מומלץ לפנות לספק האירוח כדי לבדוק אם יש לו אפשרות להציע את האפשרות הזו. באירוח עצמי, תוכלו להשתמש ב-Let's Encrypt כדי להתקין ולהגדיר אישור. ניתן גם לבדוק את העברת האתר אל מאחורי CDN או שרת proxy אחר שיכולים לספק את חיבור HTTPS.

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

  • במקרים שבהם רק קובצי cookie מסוג SameSite=Strict חסומים, אפשר להוריד את רמת ההגנה ל-Lax.
  • במקרים שבהם גם קובצי ה-cookie Strict וגם קובצי Lax חסומים וקובצי ה-cookie נשלחים אל כתובת URL מאובטחת (או מוגדרים ממנה), אפשר להנמיך את ההגנות ל-None.
    • הפתרון הזה ייכשל אם כתובת ה-URL שאליה אתם שולחים קובצי Cookie (או שממנה אתם מגדירים אותם) אינה מאובטחת. הסיבה לכך היא ש-SameSite=None מחייב את המאפיין Secure בקובצי cookie, ולכן ייתכן שקובצי cookie אלה לא יישלחו או יוגדרו בחיבור לא מאובטח. במקרה כזה, לא תוכלו לגשת לקובץ ה-cookie עד שהאתר ישודרג ל-HTTPS.
    • חשוב לזכור שזה זמני בלבד, כי בסופו של דבר, קובצי Cookie של צד שלישי יוסרו לחלוטין.

אם לא ציינתי מאפיין SameSite, איך השינוי ישפיע על קובצי ה-cookie שלי?

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

איך ההגדרות של WebSockets מושפעות מכך?

חיבורי WebSocket עדיין ייחשבו מאותו אתר אם הם באותה רמת אבטחה כמו הדף.

אותו אתר:

  • חיבור אחד (wss://) מ-https://
  • חיבור אחד (ws://) מ-http://

באתרים שונים:

  • חיבור אחד (wss://) מ-http://
  • חיבור אחד (ws://) מ-https://

צילום על ידי Julissa Capdevilla ב-UnFlood