ההגדרה של 'אותו אתר' מתפתחת וכוללת את סכימת כתובות ה-URL, כך שקישורים בין גרסאות HTTP ו-HTTPS של אתרים נחשבים עכשיו כבקשות בין אתרים. כדאי לשדרג ל-HTTPS כברירת מחדל כדי למנוע בעיות, אם אפשר, או להמשיך לקרוא כדי לקבל פרטים על ערכי המאפיין SameSite.
סכמה באותו אתר משנה את ההגדרה של אתר (אתר) רק מהדומיין שניתן לרשום scheme + דומיין שניתן לרשום. פרטים נוספים ודוגמאות זמינים הסבר על "Same-site" וגם 'same-origin'.
החדשות הטובות הן: אם האתר שלכם כבר שודרג באופן מלא ל-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 מאובטחים.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=9&hl=he)
HTTP ← HTTPS | HTTPS ← HTTP | |
SameSite=Strict
|
⛔ חסום | ⛔ חסום |
SameSite=Lax
|
✓ מותר | ✓ מותר |
SameSite=None;Secure
|
✓ מותר | ⛔ חסום |
משאבי המשנה בטעינה
שינויים שיבוצעו כאן ייחשבו כתיקון זמני בלבד בזמן לבצע שדרוג ל-HTTPS מלא.
דוגמאות למשאבי משנה כוללות תמונות, iframes ובקשות רשת שבוצעו באמצעות XHR או Fetch.
טעינת משאב משנה של סכמות שונות בדף הייתה מאפשרת בעבר
SameSite=Strict
או SameSite=Lax
קובצי cookie לשליחה או להגדרה. עכשיו זה
באותו אופן כמו כל משאב משנה אחר של צד שלישי או אתרים שונים,
המשמעות היא שכל קובצי ה-cookie מסוג SameSite=Strict
או SameSite=Lax
ייחסמו.
בנוסף, גם אם הדפדפן מאפשר למשאבים מסכמות לא מאובטחות
ייטענו בדף מאובטח, כל קובצי ה-Cookie ייחסמו בבקשות האלה
לקובצי cookie של צד שלישי או מאתרים אחרים נדרש Secure
.
![משאב משנה חוצה-סכימות שנוצר ממשאב מגרסת ה-HTTPS המאובטחת של האתר שכלול בגרסת ה-HTTP הלא מאובטחת. SameSite=Strict ו-SameSite=Lax קובצי cookie חסומים, ו-SameSite=None; מותר להשתמש בקובצי Cookie מאובטחים.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=9&hl=he)
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 קובצי cookie חסומים, ו-SameSite=None; מותר להשתמש בקובצי Cookie מאובטחים.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=9&hl=he)
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 של צד שלישי הופסק לחלוטין.
- המעקף הזה ייכשל אם כתובת ה-URL שאליה שולחים קובצי cookie (או
הגדרתן מ-) אינה מאובטחת. הסיבה לכך היא של-
איך זה משפיע על קובצי ה-cookie אם לא ציינתי מאפיין SameSite
?
קובצי cookie ללא מאפיין SameSite
נחשבים לקובצי cookie שצוינו
SameSite=Lax
ואותה התנהגות של סכמות שונות חלה על קובצי ה-Cookie האלה כמו
נו. לתשומת ליבכם: ההחרגה הזמנית לשיטות לא בטוחות עדיין חלה. ראו
הקלות Lax + POST ב-SameSite
של Chromium
לקבלת מידע נוסף, אפשר לעיין בשאלות נפוצות.
איך WebSockets מושפעים?
חיבורי WebSocket עדיין ייחשבו לאותו אתר אם הם זהים מאובטח כמו הדף.
באותו אתר:
- חיבור ל-
wss://
החל מ-https://
- חיבור ל-
ws://
החל מ-http://
בין אתרים:
- חיבור ל-
wss://
החל מ-http://
- חיבור ל-
ws://
החל מ-https://
צילום: Julissa קפדווילה על ביטול הפתיחה