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

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

Steven Bingler

Rowan Merewood

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

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

סכמה באותו אתר משנה את ההגדרה של אתר (אתר) רק מהדומיין שניתן לרשום scheme + דומיין שניתן לרשום. פרטים נוספים ודוגמאות זמינים הסבר על "Same-site" וגם 'same-origin'.

מונח מפתח: המשמעות היא שגרסת ה-HTTP לא מאובטחת של אתר, למשל http://website.example, וגרסת ה-HTTPS המאובטחת של האתר הזה, https://website.example, נחשבות עכשיו בכמה אתרים אחת לשנייה.

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

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

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

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

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

מונח מפתח: בדוגמאות הבאות, שבהן לכל כתובות ה-URL יש דומיין זהה שניתן לרשום, למשל site.example, אבל סכימות שונות, כמו http://site.example לעומת https://site.example, הן נקראות סכימות שונות.

ניווט

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

מעבר בין סכמות שונות מ-HTTP ל-HTTPS.

	HTTP ← HTTPS	HTTPS ← HTTP
SameSite=Strict	⛔ חסום	⛔ חסום
SameSite=Lax	✓ מותר	✓ מותר
SameSite=None;Secure	✓ מותר	⛔ חסום

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

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

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

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

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

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

דף 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.

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

שליחת טופס חוצה-סכמות מ-HTTP ל-HTTPS.

	HTTP ← HTTPS	HTTPS ← HTTP
SameSite=Strict	⛔ חסום	⛔ חסום
SameSite=Lax	⛔ חסום	⛔ חסום
SameSite=None;Secure	✓ מותר	⛔ חסום

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

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

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

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

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

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

• "צריך להעביר לגמרי ל-HTTPS כדי שקובצי cookie יישלחו לאותו אתר משאבי משנה" או "להעביר לגמרי ל-HTTPS כדי להמשיך לאפשר קובצי cookie be set bySame-site subresources" – אזהרות שקובץ ה-cookie יהיה ייחסם בגרסה עתידית של Chrome.
• "צריך להעביר לגמרי ל-HTTPS כדי שקובצי cookie יישלחו למשאבי משנה באותו אתר" או "להעביר לגמרי ל-HTTPS כדי לאפשר הגדרה של קובצי Cookie על ידי אותו אתר subresources" – אזהרות שקובץ ה-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 אבטחה מחמירה-תעבורה (HSTS) וההוראה includeSubDomain. עם HSTS + includeSubDomain אפילו אם אחד מהדפים שלך כולל בטעות קישור לא מאובטח, הדפדפן להשתמש במקום זאת באופן אוטומטי בגרסה המאובטחת.

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

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

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

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

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

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

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

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

באותו אתר:

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

בין אתרים:

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

צילום: Julissa קפדווילה על ביטול הפתיחה