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

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

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

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

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

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

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

דוגמאות למשאבי משנה כוללות תמונות, רכיבי iframe ובקשות רשת שנוצרות באמצעות 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 ‫✓ מותר ⛔ נחסם

פרסום טופס

בעבר, פרסום בין גרסאות של אתר עם סכימות שונות היה מאפשר לשלוח קובצי 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, הכרטיסייה 'בעיה' בכלי הפיתוח תכלול בעיות שקשורות ל-Schemeful Same-Site. יכול להיות שהבעיות הבאות יודגשו באתר שלכם.

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

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

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

  • ‫"Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" או "Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources" – אזהרות שקובץ ה-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.

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

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

  • ‫"Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match."
  • ‫"Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match."

שאלות נפוצות

האתר שלי כבר זמין באופן מלא ב-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, ואותה התנהגות חוצת-סכימות חלה גם על קובצי ה-Cookie האלה. חשוב לזכור שהחריג הזמני לשיטות לא בטוחות עדיין חל. מידע נוסף זמין במאמר בנושא אמצעי ההגנה Lax + POST בשאלות הנפוצות של Chromium SameSite.

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

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

באותו אתר:

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

בין אתרים:

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