עדכונים
- 7 ביולי 2022: הסטטוס הנוכחי עודכן ונוספה הגדרת המרחב של כתובות ה-IP.
- 27 באפריל 2022: הודעה מעודכנת לגבי ציר הזמן.
- 7 במרץ 2022: הודענו על החזרה לגרסאות קודמות אחרי שזוהו בעיות ב-Chrome 98.
מבוא
במסגרת המפרט גישה לרשת פרטית (PNA), ב-Chrome מוציאים משימוש את הגישה הישירה לנקודות קצה (endpoint) ברשת פרטית מאתרים ציבוריים.
מערכת Chrome תתחיל לשלוח בקשת קדם-הפעלה של CORS לפני כל בקשת רשת פרטית למשאב משנה, שבה תתבקשו לספק הרשאה מפורשת משרת היעד. בקשת קדם-ההפעלה כוללת כותרת חדשה, Access-Control-Request-Private-Network: true
, והתגובה אליה חייבת לכלול כותרת תואמת, Access-Control-Allow-Private-Network: true
.
המטרה היא להגן על המשתמשים מפני מתקפות פישינג באתרים שונים (CSRF) שמטרגטות נתבים ומכשירים אחרים ברשתות פרטיות. ההתקפות השפיעו על מאות אלפי משתמשים ואפשרו לתוקפים להפנות אותם לשרתים זדוניים.
תוכנית השקה
השינוי יתבצע ב-Chrome בשני שלבים כדי לתת לאתרים זמן לשים לב לשינוי ולהתכוונן בהתאם.
בגרסה 104 של Chrome:
- מתבצעת ניסויים ב-Chrome על ידי שליחת בקשות קדם-הפעלה לפני בקשות למשאבי משנה של רשת פרטית.
- בכשלים של קדם-ההפעלה מוצגים רק אזהרות בכלי הפיתוח, בלי להשפיע על בקשות הרשת הפרטית בדרכים אחרות.
- Chrome אוסף נתוני תאימות ופונה לאתרים הגדולים ביותר שמושפעים.
- אנחנו מצפים שהיא תהיה תואמת באופן נרחב לאתרים קיימים.
ב-Chrome בגרסה 113 לכל הפחות:
- זה יתחיל רק אם וכאשר נתוני התאימות יצביעו על כך שהשינוי בטוח מספיק, ופנינו אליך ישירות במקרה הצורך.
- Chrome אוכף שבקשות קדם-הפעלה חייבות להצליח, אחרת הן ייכשלו.
- תקופת ניסיון להוצאה משימוש מתחילה באותו זמן כדי לאפשר לאתרים שהושפעו מהשלב הזה לבקש הארכת זמן. תקופת הניסיון תימשך 6 חודשים לפחות.
מהי גישה לרשת פרטית (PNA)
גישה לרשת פרטית (לשעבר CORS-RFC1918) מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשתות פרטיות.
Chrome כבר יישם חלק מהמפרט: החל מגרסה 96 של Chrome, רק הקשרים מאובטחים מורשים לשלוח בקשות רשת פרטית. קראו את הפוסט הקודם בבלוג שלנו לפרטים נוספים.
המפרט גם מרחיב את הפרוטוקול של שיתוף משאבים בין מקורות (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,
כתובות unicast מקומיות ייחודיות של IPv6 fc00::/7
שמוגדרות ב-RFC4193,
כתובות URL-מקומיות (link-local) של כתובות IPv6 / RFC15/RFC4} IPv6.fe80::/10
RFC4291
המרחב של כתובות ה-IP הציבוריות מכיל את כל שאר הכתובות שלא צוינו קודם.
כתובת IP מקומית נחשבת פרטית יותר מכתובת IP פרטית, שנחשבת כפרטית יותר מכתובת IP ציבורית.
![הבקשות הן פרטיות כשרשת זמינה יותר שולחת בקשה לרשת פחות זמינה.](https://developer.chrome.com/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=5&hl=he)
מידע נוסף זמין במאמר משוב רצוי: 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 נשלחות לכל הבקשות ברשת הפרטית, ללא קשר לשיטת הבקשה ולמצב. הם נשלחים לפני הבקשות במצב cors
, וגם במצב no-cors
ובכל המצבים האחרים. הסיבה לכך היא שכל בקשות הרשת הפרטית יכולות לשמש להתקפות CSRF, ללא קשר למצב הבקשה ואם תוכן התגובה זמין או לא זמין ליוזם.
בקשות קדם-הפעלה ל-PNA נשלחות גם לבקשות ממקור זהה, אם כתובת ה-IP של היעד פרטית יותר ממי שפתח אותה. הדבר שונה מבקשות CORS רגילות, שבהן בקשות קדם-הפעלה מיועדות רק לבקשות ממקורות שונים. בקשות קדם-הפעלה לבקשות מאותו מקור מגינות מפני התקפות DNS Rebinding.
דוגמאות
ההתנהגות הגלויה תלויה במצב הבקשה.
מצב ללא 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
כל בקשת קדם-הפעלה שנכשלה תגרום לאחזור. כך תוכלו לבדוק אם האתר שלכם יפעל אחרי השלב השני של תוכנית ההשקה. אפשר לאבחן שגיאות בדיוק כמו אזהרות באמצעות החלוניות של כלי הפיתוח שצוינו למעלה.
מה לעשות אם האתר שלך מושפע
כשהשינוי הזה יושק בגרסה 104 של Chrome, הוא לא צפוי לגרום לקריסה של אף אתר. עם זאת, מומלץ מאוד לעדכן את נתיבי הבקשות שהושפעו, כדי להבטיח שהאתר ימשיך לפעול כצפוי.
יש שני פתרונות זמינים:
- טיפול בבקשות קדם-הפעלה בצד השרת
- השבתת בדיקות 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 ירחיב את הבדיקות של הגישה לרשת הפרטית כך שהן יכסו עובדי אינטרנט: עובדים ייעודיים, עובדים משותפים ו-Service Workers. אנחנו פועלים זמנית כדי ש-Chrome 107 יתחיל להציג אזהרות.
לאחר מכן, Chrome ירחיב את הבדיקות של הגישה לרשת הפרטית כך שיכללו ניווטים, כולל iframes וחלונות קופצים. אנחנו פועלים זמנית כדי ש-Chrome 108 יתחיל להציג אזהרות.
בשני המקרים נמשיך להפעיל שיקול דעת בהשקה הדרגתית דומה, כדי לתת למפתחי האתרים זמן להתאים ולהעריך את סיכון התאימות.
אישורים
תמונת השער מאת מארק אולסן ב-UnFlood.