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

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

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

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) היה מאפשר לשלוח קובצי cookie מסוג SameSite=Strict. המערכת מתייחסת לכך עכשיו כניווט בין אתרים, כלומר קובצי ה-cookie מסוג SameSite=Strict ייחסמו.

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

טעינת משאבים משניים

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

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

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

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

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

שליחת טופס באמצעות POST

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

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

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

איך בודקים את האתר?

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

החל מ-Chrome 86, הכרטיסייה 'בעיה' בכלי הפיתוח תכלול בעיות של 'אתרים באותה סכימה'. יכול להיות שהבעיות הבאות יופיעו באתר שלכם.

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

  • "צריך לעבור ל-HTTPS באופן מלא כדי להמשיך לשלוח קובצי cookie בבקשות באותו אתר" – אזהרה על כך שקובץ ה-cookie ייחסם בגרסה עתידית של Chrome.
  • "Migrate entirely to HTTPS to have cookies sent on same-site requests" (צריך לעבור ל-HTTPS באופן מלא כדי לשלוח קובצי cookie בבקשות באותו אתר) – אזהרה על כך שקובץ ה-cookie נחסם.

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

  • "צריך לעבור ל-HTTPS באופן מלא כדי להמשיך לשלוח קובצי cookie למשאבים משניים באותו אתר" או "צריך לעבור ל-HTTPS באופן מלא כדי להמשיך לאפשר למשאבים משניים באותו אתר להגדיר קובצי cookie" – אזהרות על כך שקובץ ה-cookie יושחם בגרסה עתידית של Chrome.
  • "Migrate entirely to HTTPS to have cookies sent to same-site subresources" (צריך לעבור ל-HTTPS כדי שקובצי cookie יישלחו למשאבים משניים באותו אתר) או "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources" (צריך לעבור ל-HTTPS כדי לאפשר לקובצי cookie להיקבע על ידי משאבים משניים באותו אתר) – אזהרות על כך שקובץ ה-cookie נחסם. האזהרה השנייה עשויה להופיע גם כששולחים טופס באמצעות POST.

פרטים נוספים זמינים במאמר טיפים לבדיקות ולניפוי באגים של Schemeful Same-Site.

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

  • "קובץ ה-cookie cookie_name בקרוב ייחשב כקובץ cookie בין אתרים ביחס ל-http://site.example/ כי הסכימה לא תואמת".
  • "קובץ ה-cookie cookie_name טופל כקובץ cookie בין אתרים באתר 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 של צד שלישי יוצאו משימוש לגמרי.

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

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

איך WebSockets מושפעים?

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

באותו אתר:

  • חיבור wss:// מ-https://
  • חיבור ws:// מ-http://

בין אתרים:

  • חיבור wss:// מ-http://
  • חיבור ws:// מ-https://

תמונה של Julissa Capdevilla ב-Unsplash