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