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

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

עדכונים

• 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 בשני שלבים כדי לתת לאתרים זמן לשים לב לשינוי ולהתכוונן בהתאם.

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

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

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

יש שני פתרונות זמינים:

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

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

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

אישורים

תמונת השער מאת מארק אולסן ב-UnFlood.