גישה לרשת פרטית: הצגת קדם-הפעלה

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

עדכונים

• 7 ביולי 2022: עדכנו את הסטטוס הנוכחי והוסיפה הגדרה של מרחב כתובות ה-IP.
• 27 באפריל 2022: עדכון של לוח הזמנים.
• 7 במרץ 2022: הודענו על ביטול השדרוג לאחר שגילינו בעיות ב-Chrome 98.

מבוא

אנחנו ב-Chrome מוציאים משימוש את הגישה הישירה לנקודות קצה של רשת פרטית מאתרים ציבוריים, כחלק מהמפרט של גישה לרשת פרטית (PNA).

Chrome יתחיל לשלוח בקשת קדם-הפעלה של CORS לפני כל בקשת רשת פרטית של משאב משנה, שתבקש הרשאה מפורשת משרת היעד. בקשת קדם-ההפעלה הזו תעביר כותרת חדשה, Access-Control-Request-Private-Network: true, והתגובה אליה צריכה לכלול כותרת מתאימה, Access-Control-Allow-Private-Network: true.

המטרה היא להגן על המשתמשים מפני התקפות זיוף בקשות בין אתרים (CSRF) שמטרגטות נתבים ומכשירים אחרים ברשתות פרטיות. ההתקפות האלה השפיעו על מאות אלפי משתמשים, והתוקפים השתמשו בהן כדי להפנות אותם לשרתים זדוניים.

תוכנית ההשקה

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

1. בגרסה 104 של Chrome:

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

2. ב-Chrome 113 לכל המוקדם:

   • התהליך הזה יתחיל רק אם נתוני התאימות יצביעו על כך שהשינוי בטוח מספיק, ורק אחרי שנפנה ישירות אל החשבונות הרלוונטיים במקרים שבהם נצטרך לעשות זאת.
   • Chrome אוכף את הדרישה שבקשות קדם ההפעלה חייבות להצליח, אחרת הוא ידחה את הבקשות.
   • תקופת ניסיון להוצאה משימוש מתחילה באותו זמן כדי לאפשר לאתרים שמושפעים מהשלב הזה לבקש הארכת זמן. תקופת הניסיון תימשך לפחות 6 חודשים.

מהי גישה לרשת פרטית (PNA)

גישה לרשת פרטית (לשעבר CORS-RFC1918) מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשתות פרטיות.

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

המפרט גם מרחיב את פרוטוקול שיתוף המשאבים בין מקורות (CORS), כך שאתרים צריכים לבקש באופן מפורש הרשאה מהשרתים ברשתות פרטיות לפני שמותר להם לשלוח בקשות שרירותיות.

איך PNA מסווג כתובות IP ומזהה רשת פרטית

כתובות ה-IP מסווגות לשלושה רווחים של כתובות IP: - public - private - local

מרחב כתובות ה-IP המקומי מכיל כתובות IP שהן כתובות loopback של IPv4‏ (127.0.0.0/8) שמוגדרות בקטע 3.2.1.3 של RFC1122, או כתובות loopback של 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 unicast fc00::/7 שמוגדרות ב-RFC4193, כתובות IPv15/ IPv6/fe80::/10RFC4291

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

בקשות קדם-הפעלה ל-PNA נשלחות גם לבקשות ממקור זהה, אם כתובת ה-IP של היעד פרטית יותר מזו של הגורם היוזם. היא לא דומה ל-CORS רגיל, שבו בקשות קדם-ההפעלה רלוונטיות רק לבקשות ממקורות שונים. בקשות Preflight לבקשות מאותו מקור מגינות מפני התקפות של קישור מחדש של DNS.

דוגמאות

ההתנהגות הנצפית תלויה במצב הבקשה.

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

אפשר גם לראות ולנתח בחלונית הרשת את הבקשות המושפעות של בדיקת טרום-המרחק:

אם הבקשה הייתה מפעילה קדם-הפעלה רגיל של CORS ללא כללי גישה לרשת פרטית, יכול להיות שיופיעו שתי קדם-הפעלה בחלונית של הרשת, כך שההפעלה הראשונה תמיד נכשלה. זהו באג ידוע, ואפשר להתעלם ממנו.

כדי לבדוק מה קורה אם הצלחת בדיקת טרום-המריא אוכפת, אפשר להעביר את הארגומנט הבא בשורת הפקודה, החל מ-Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

כל בקשה שנכשלת לפני הטיסה תגרום לכשל באחזור. כך תוכלו לבדוק אם האתר שלכם יפעל אחרי השלב השני של תוכנית ההשקה. אפשר לאבחן שגיאות באותו אופן שבו מאבחנים אזהרות, באמצעות החלוניות של DevTools שצוינו למעלה.

מה לעשות אם האתר שלך מושפע

כשהשינוי הזה יושק בגרסה 104 של Chrome, הוא לא אמור לגרום לשיבושים באתרים. עם זאת, מומלץ מאוד לעדכן את נתיבי הבקשות המושפעים כדי לוודא שהאתר ימשיך לפעול כצפוי.

יש לכם שתי אפשרויות:

1. טיפול בבקשות קדם-הפעלה בצד השרת
2. השבתת בדיקות 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, וגם כותרות אחרות לפי הצורך.

בדוגמאות מפורטות דוגמאות קונקרטיות.

השבתת בדיקות גישה לרשת פרטית באמצעות מדיניות הארגון

אם יש לכם הרשאת אדמין על המשתמשים, תוכלו להשבית את הבדיקות של גישה לרשתות פרטיות באמצעות אחת מהמדיניות הבאות:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

מידע נוסף זמין במאמר הסבר על ניהול המדיניות של Chrome.

נשמח לקבל ממך משוב

אם אתם מארחים אתר ברשת פרטית שמצפה לבקשות מרשתות ציבוריות, צוות Chrome ירצה לקבל מכם משוב ותרחישי שימוש. כדי להודיע לנו על כך, צריך לדווח על הבעיה ב-Chromium בכתובת crbug.com ולהגדיר את הרכיב כ-Blink>SecurityFeature>CORS>PrivateNetworkAccess.

המאמרים הבאים

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

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

בשני המקרים, נמשיך בזהירות בהשקה בשלבים דומים, כדי לתת למפתחי האינטרנט זמן להסתגל ולהעריך את סיכוני התאימות.

תודות

תמונת השער של Mark Olsen ב-Unsplash.