עדכונים
- 7 ביולי 2022: הסטטוס הנוכחי עודכן ונוספה הגדרת מרחב של כתובת IP.
- 27 באפריל 2022: ההודעה על לוח הזמנים עודכנה.
- 7 במרץ 2022: הודעה על החזרה למצב הקודם לאחר שהתגלו בעיות ב Chrome 98.
מבוא
Chrome מוציא משימוש את הגישה הישירה לנקודות קצה (endpoint) ציבוריות ברשת פרטית אתרים במסגרת גישה לרשת פרטית (PNA) למפרט.
Chrome יתחיל לשלוח בקשת קדם-הפעלה של CORS לפני כל בקשת רשת פרטית למשאב משנה, שתתבקש
לקבלת אישור מפורש משרת היעד. בקשת קדם-ההפעלה הזו
להכיל כותרת חדשה, Access-Control-Request-Private-Network: true, ואת
התגובה אליה חייבת לכלול כותרת תואמת,
Access-Control-Allow-Private-Network: true.
המטרה היא להגן על המשתמשים מפני מתקפות של גניבת זהות משתמש - Cross-Site Request Forgery (CSRF) שמטרגט נתבים ומכשירים אחרים ברשתות פרטיות. המתקפות האלה השפיעו על מאות אלפי משתמשים, ומאפשרת לתוקפים להפנות אותם לשרתים זדוניים.
תוכנית השקה
נשיק את השינוי הזה ב-Chrome בשני שלבים כדי לתת לאתרים זמן התראה את השינוי ולהתאים אותו בהתאם.
בגרסה 104 של Chrome:
- ניסויים ב-Chrome על ידי שליחת בקשות קדם-הפעלה לפני רשת פרטית בקשות למשאבי משנה.
- כשלים בקדם-ההפעלה מוצגים רק אזהרות בכלי הפיתוח, ללא אפשרות אחרת שמשפיעות על בקשות הרשת הפרטית.
- Chrome אוסף נתוני תאימות ומגיע למידע הגדול ביותר שמושפע אתרים.
- אנחנו מצפים שהגרסה הזו תתאים באופן נרחב לאתרים קיימים.
ב-Chrome 113 לכל המוקדם:
- השינוי הזה יתחיל רק אם וכאשר נתוני התאימות מצביעים על הוא בטוח מספיק ופנינו ישירות למקרה הצורך.
- Chrome אוכף שבקשות קדם-ההפעלה חייבות להצליח, אחרת הן ייכשלו הבקשות.
- תקופת ניסיון של הוצאה משימוש מתחילה ב- באותו זמן כדי לאפשר לאתרים שהושפעו מהשלב הזה לבקש הארכת זמן. תקופת הניסיון תימשך 6 חודשים לפחות.
מהי גישה לרשת פרטית (PNA)
גישה לרשת הפרטית (לשעבר CORS-RFC1918) מגביל את היכולת של אתרים לשלוח בקשות לשרתים פרטיים עמוקה מאוד,
Chrome כבר הטמיע חלק מהמפרט: החל מ-Chrome 96, רק הקשרים מאובטחים יכולים לשלוח בקשות רשת פרטית. עיינו ב פרטים נוספים על הפוסט הקודם בבלוג.
המפרט גם מרחיבים את השימוש בשיתוף משאבים בין מקורות (CORS) כך שאתרים חייבים כעת לבקש מענק באופן מפורש משרתים ברשתות פרטיות לפני שיורשה לשלוח בקשות שרירותיות.
איך PNA מסווג כתובות IP ומזהה רשת פרטית
כתובות ה-IP מסווגות לשלושה רווחים של כתובות IP:
- public
- private
- local
מרחב כתובות IP מקומיות כולל כתובות IP מסוג IPv4
כתובות בלולאה חוזרת (127.0.0.0/8) מוגדרות בסעיף 3.2.1.3 של RFC1122
או כתובות הלולאה החוזרת של IPv6 (::1/128) שמוגדרות בסעיף 2.5.3 של RFC4291.
מרחב כתובות IP פרטי מכיל כתובות IP שיש להן משמעות בלבד
ברשת הנוכחית, כולל 10.0.0.0/8, 172.16.0.0/12 ו
192.168.0.0/16 מוגדר ב-RFC1918,
כתובות קישור מקומיות 169.254.0.0/16 שמוגדרות ב-RFC3927,
כתובות פרוטוקול IPv6 מקומיות ייחודיות fc00::/7 שהוגדרו בתקן RFC4193,
כתובות IPv6 מסוג IPv6 מסוג link-local fe80::/10 מוגדרות בסעיף 2.5.6 של RFC4291
וכתובות IPv4 שממופות על ידי IPv4 שבהן כתובת ה-IPv4 הממופה היא עצמה פרטית.
המרחב של כתובות ה-IP הציבוריות מכיל את כל הכתובות האחרות שלא צוינו קודם.
כתובת IP מקומית נחשבת פרטית יותר מאשר כתובת IP פרטית נחשבת פרטית יותר מכתובת IP ציבורית.
מידע נוסף זמין במאמר המשוב הרצוי: CORS לרשתות פרטיות (RFC1918).
בקשות קדם-הפעלה
רקע
בקשות קדם-הפעלה הן מנגנון שנעשה בו שימוש בתקן שיתוף משאבים בין מקורות (CORS) לבקש הרשאה מאתר יעד לפני ששולחים אליו בקשת HTTP שעלולות להיות להם תופעות לוואי. הפעולה הזאת מבטיחה ששרת היעד יבין פרוטוקול CORS ומפחית באופן משמעותי את הסיכון להתקפות CSRF.
בקשת ההרשאה נשלחת כבקשת HTTP OPTIONS עם כותרות של בקשות CORS ספציפיות
שמתאר את בקשת ה-HTTP הקרובה. התשובה חייבת לכלול כותרות תגובה ספציפיות של CORS
להסכים במפורש לבקשה הקרובה.
מה חדש בגישה לרשת הפרטית
זוג חדש של כותרות בקשה ותגובה נוסף לבקשות קדם-הפעלה:
- המדיניות
Access-Control-Request-Private-Network: trueמוגדרת בכל בקשות קדם-ההפעלה של PNA - חובה להגדיר את
Access-Control-Allow-Private-Network: trueבכל תגובות קדם-ההפעלה של PNA
בקשות קדם-הפעלה של PNA נשלחות לכל בקשות הרשת הפרטית,
בלי קשר לשיטת הבקשה
mode. הן נשלחות
לפני בקשות במצב cors וגם ב-no-cors ובכל המצבים האחרים. הזה
היא מכיוון שכל בקשות הרשת הפרטית יכולות לשמש להתקפות CSRF,
בלי קשר למצב הבקשה ואם תוכן התשובות נוצר
זמינים ליוזם המודעה.
בקשות קדם-הפעלה ל-PNA נשלחות גם לבקשות ממקור זהה, אם כתובת ה-IP של היעד פרטית יותר מאשר היוזם. זה שונה מבדרך כלל CORS, כאשר בקשות קדם-ההפעלה הן רק לבקשות ממקורות שונים. קדם-הפעלה בקשות לבקשות ממקור זהה להגנה מפני התקפות DNS rebinding
דוגמאות
ההתנהגות הניתנת למדידה תלויה בכך request's mode.
מצב No-CORS
יש לומר https://foo.example/index.html הטמעות
<img src="https://bar.example/cat.gif" alt="dancing cat"/>, וגם
הכתובת bar.example מובילה ל-192.168.1.1, כתובת IP פרטית לפי
RFC 1918.
תחילה Chrome שולח בקשת קדם-הפעלה:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
כדי שהבקשה תתבצע בהצלחה, השרת צריך להגיב עם:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
לאחר מכן Chrome ישלח את הבקשה עצמה:
HTTP/1.1 GET /cat.gif
...
אליה השרת יכול להגיב כרגיל.
מצב CORS
נניח ש-https://foo.example/index.html מריץ את הקוד הבא:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
שוב, אומרים ש-bar.example הופך ל-192.168.1.1.
תחילה Chrome שולח בקשת קדם-הפעלה:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
כדי שהבקשה תתבצע בהצלחה, השרת צריך להגיב עם:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
לאחר מכן Chrome ישלח את הבקשה עצמה:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
שאליו השרת יכול להגיב בהתאם לכללי CORS הרגילים:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
איך יודעים אם האתר מושפע?
החל מגרסה 104 של Chrome, אם מזוהה בקשת רשת פרטית, מתבצעת קדם-הפעלה לפני כן תישלח בקשה. אם בקשת קדם-ההפעלה הזו תיכשל, הבקשה עדיין תישלח, אבל תוצג אזהרה בכלי הפיתוח. חלונית בעיות.
אפשר להציג ולאבחן את בקשות קדם-ההפעלה שהושפעו גם בחלונית הרשת:
אם הבקשה שלכם הייתה מפעילה קדם-הפעלה רגילה של CORS ללא כללי גישה לרשת הפרטית, ייתכן שיופיעו שתי קדם-הפעלה רשת סלולרית, כך שהתצוגה הראשונה תמיד נכשלה. זהו באג ידוע, ואפשר להתעלם ממנו בבטחה.
כדי לבדוק מה קורה אם נאכפים הצלחה של קדם-הפעלה: מעבירים את הארגומנט הבא של שורת הפקודה, החל מ-Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
כל בקשת קדם-הפעלה שנכשלה תגרום לאחזור נכשל. כך אפשר כדי לבדוק אם האתר שלכם יפעל אחרי השלב השני של תוכנית ההשקה. ניתן לאבחן שגיאות בדיוק כמו אזהרות שמשתמשים בחלוניות של כלי הפיתוח שצוינו למעלה.
מה לעשות אם האתר שלך מושפע
כשהשינוי הזה יושק ב-Chrome 104, הוא לא צפוי להיפגע האתר. עם זאת, מומלץ מאוד לעדכן את נתיבי הבקשות המושפעים כדי כדי להבטיח שהאתר ימשיך לפעול כמצופה.
יש שני פתרונות שזמינים לך:
- טיפול בבקשות קדם-הפעלה בצד השרת
- השבתת בדיקות PNA באמצעות מדיניות הארגון
טיפול בבקשות קדם-הפעלה בצד השרת
צריך לעדכן את שרת היעד של כל האחזורים שהושפעו כדי לטפל בקדם-הפעלה של PNA בקשות. קודם כל להטמיע תמיכה בבקשות קדם-הפעלה רגילות של CORS במסלולים המושפעים. לאחר מכן מוסיפים תמיכה בשתי כותרות התשובה החדשות.
כשהשרת מקבל בקשת קדם-הפעלה (בקשת OPTIONS עם CORS)
), השרת צריך לבדוק אם יש
הכותרת Access-Control-Request-Private-Network: true. אם הכותרת
קיימת בבקשה, השרת צריך לבדוק את הכותרת Origin ואת
את נתיב הבקשה לצד כל מידע רלוונטי אחר (כמו
Access-Control-Request-Headers) כדי לוודא שהבקשה תאושר באופן בטוח.
בדרך כלל כדאי לאפשר גישה למקור אחד שבשליטתכם.
לאחר שהשרת החליט לאפשר את הבקשה, הוא אמור להגיב
204 No Content (או 200 OK) עם כותרות ה-CORS הנדרשות וה-PNA החדש
הכותרת. הכותרות האלה כוללות את Access-Control-Allow-Origin וגם
Access-Control-Allow-Private-Network: true, וגם אחרים לפי הצורך.
אפשר לעיין בדוגמאות לתרחישים קונקרטיים.
השבתת בדיקות גישה לרשת פרטית באמצעות מדיניות הארגון
אם יש לך שליטה מנהלית על המשתמשים שלך, ניתן להשבית את התכונה 'פרטי' בדיקות גישה לרשת לפי אחד מכללי המדיניות הבאים:
מידע נוסף זמין במאמר הסבר על ניהול המדיניות של Chrome.
נשמח לקבל ממך משוב
אם אתם מארחים אתר ברשת פרטית שמצפה לבקשות ממשתמשים
ברשתות ציבוריות, צוות Chrome מתעניין במשוב ובתרחישים לדוגמה שלך.
כדי לדווח לנו, ניתן לדווח על בעיה ב-Chromium בכתובת crbug.com ולהגדיר
את הרכיב אל Blink>SecurityFeature>CORS>PrivateNetworkAccess.
המאמרים הבאים
בשלב הבא, Chrome ירחיב את בדיקות הגישה לרשת הפרטית כדי לכסות web works: עובדים ייעודיים, עובדים משותפים ועובדי שירות. אנחנו מתכננים לבצע כדי ש-Chrome 107 יתחיל להציג אזהרות.
לאחר מכן, Chrome ירחיב את בדיקות הגישה לרשת הפרטית כדי לכסות ניווטים, כולל iframes וחלונות קופצים. אנחנו מתכננים להפעיל את Chrome 108 שמציגה אזהרות.
בשני המקרים, נמשיך זהירות עם השקה הדרגתית דומה, כדי לתת למפתחי אתרים זמן להתאים ולהעריך את סיכון התאימות.
אישורים
תמונת השער של מארק אולסן מופעלת ביטול הפתיחה.