צמצום הסיכונים שקשורים לחשיפת מכשירים ושרתים ברשת הפנימית של לקוח לאינטרנט באופן לא מכוון.
אתרים זדוניים ששולחים בקשות למכשירים ולשרתים שמתארחים ברשת פרטית הם איום מזה זמן רב. לדוגמה, תוקפים יכולים לשנות את ההגדרות של נתב אלחוטי כדי לאפשר התקפות Man-in-the-Middle. CORS-RFC1918 היא הצעה לחסום בקשות כאלה כברירת מחדל בדפדפן, ולחייב מכשירים פנימיים להביע הסכמה לבקשות מהאינטרנט הציבורי.
כדי להבין איך השינוי הזה משפיע על סביבת האינטרנט, צוות Chrome מחפש משוב ממפתחים שמפתחים שרתים לרשתות פרטיות.
מה הבעיה במצב הקיים?
שרתי אינטרנט רבים פועלים ברשת פרטית – נתבים אלחוטיים, מדפסות, אתרי אינטראנט, שירותי ארגון ומכשירי האינטרנט של הדברים (IoT) הם רק חלק מהם. הם עשויים להיראות בסביבה בטוחה יותר מזו של שרתי ה-DNS שנחשפים לציבור, אבל תוקפים יכולים לנצל לרעה את השרתים האלה באמצעות דף אינטרנט כשרתי proxy. לדוגמה, אתרים זדוניים יכולים להטמיע כתובת URL, שכאשר הקורבן פשוט מציג אותה (בדפדפן עם תמיכה ב-JavaScript), היא מנסה לשנות את הגדרות שרת ה-DNS בנתב הפס הרחב הביתי של הקורבן. סוג ההתקפה הזה נקרא פירמיינג בנסיעה, והוא התקיים בשנת 2014. יותר מ-300,000 נתבים אלחוטיים נחשפו לניצול לרעה, שבו השתנו הגדרות ה-DNS שלהם והתוקפים השתמשו בהם כדי להפנות משתמשים לשרתי זדון.
CORS-RFC1918
כדי לצמצם את האיום של התקפות דומות, קהילת האינטרנט מביאה את CORS-RFC1918 – שיתוף משאבים בין מקורות (CORS) שמותאם לרשתות פרטיות שמוגדרות ב-RFC1918.
דפדפנים שמטמיעים את CORS בודקים עם משאבי היעד אם מותר לטעון אותם ממקור אחר. כדי לעשות זאת, אפשר להשתמש בכותרות נוספות בתוך שורת הקוד שמתארות את הגישה, או במנגנון שנקרא בקשות לבדיקה מראש (preflight), בהתאם לרמת המורכבות. מידע נוסף זמין במאמר שיתוף משאבים בין מקורות.
כשמשתמשים ב-CORS-RFC1918, הדפדפן חוסם כברירת מחדל את טעינת המשאבים ברשת הפרטית, מלבד אלה שהשרת מאפשר באופן מפורש באמצעות CORS ודרך HTTPS. האתר ששולח בקשות למשאבים האלה יצטרך לשלוח כותרות CORS, והשרת יצטרך לציין במפורש שהוא מקבל את הבקשה ממקורות שונים על ידי מענה עם כותרות CORS תואמות. (כותרות ה-CORS המדויקות עדיין בפיתוח).
מפתחים של מכשירים או שרתים כאלה יתבקשו לבצע שתי פעולות:
- חשוב לוודא שהאתר ששולח בקשות לרשת פרטית מוצג באמצעות HTTPS.
- מגדירים את תמיכת השרת ב-CORS-RFC1918 ומגיבים עם כותרות HTTP צפויות.
אילו סוגי בקשות מושפעים?
הבקשות המושפעות כוללות:
- בקשות מהרשת הציבורית לרשת פרטית
- בקשות מרשת פרטית לרשת מקומית
- בקשות מהרשת הציבורית לרשת מקומית
רשת פרטית: יעד שמתאים למרחב כתובות פרטי שמוגדר בקטע 3 של RFC1918 ב-IPv4, כתובת IPv6 שממופת ל-IPv4 כאשר כתובת ה-IPv4 הממופת היא פרטית בעצמה, או כתובת IPv6 מחוץ לרשתות המשנה ::1/128, 2000::/3 ו-ff00::/8.
רשת מקומית
יעד שמתקבל במרחב 'loopback' (127.0.0.0/8) שמוגדר בקטע 3.2.1.3 של RFC1122 של IPv4, במרחב 'link-local' (169.254.0.0/16) שמוגדר בקטע 3 של RFC3927 של IPv4, בקידומת 'Unique Local Address' (fc00::/7) שמוגדר בקטע 3 של RFC4193 של IPv6, או בקידומת 'link-local' (fe80::/10) שמוגדר בקטע 2.5.6 של RFC4291 של IPv6.
רשת ציבורית כל שאר הרשתות.
התוכניות של Chrome להפעלת CORS-RFC1918
אנחנו מוסיפים את CORS-RFC1918 ל-Chrome בשני שלבים:
שלב 1: בקשות למשאבים ברשת פרטית יתקבלו רק מדפי אינטרנט מסוג HTTPS
בגרסה 87 של Chrome נוסף דגל שמחייב אתרים ציבוריים ששולחים בקשות למשאבי רשת פרטיים להשתמש ב-HTTPS. אפשר להיכנס אל about://flags#block-insecure-private-network-requests כדי להפעיל אותה. כשהדגל הזה מופעל, כל הבקשות למשאב ברשת פרטית מאתר HTTP ייחסמו.
החל מ-Chrome 88, שגיאות CORS-RFC1918 ידווחו במסוף כשגיאות מדיניות CORS.
בחלונית Network בכלי הפיתוח ל-Chrome, אפשר להפעיל את התיבה Blocked Requests כדי להתמקד בבקשות חסומים:
ב-Chrome 87, שגיאות מסוג CORS-RFC1918 מדווחות במסוף כלי הפיתוח רק בתור ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
אתם יכולים לנסות זאת בעצמכם באמצעות אתר הבדיקה הזה.
שלב 2: שליחת בקשות קדם-הפעלה עם כותרת מיוחדת
בעתיד, בכל פעם שאתר ציבורי ינסה לאחזר משאבים מרשת פרטית או מקומית, Chrome ישלח בקשה מקדימה לפני הבקשה בפועל.
הבקשה תכלול כותרת Access-Control-Request-Private-Network: true בנוסף לכותרות אחרות של בקשות CORS. בין היתר, הכותרות האלה מזהות את המקור שממנו נשלחה הבקשה, ומאפשרות לבצע בקרה מפורטת על הגישה. השרת יכול להשיב עם כותרת Access-Control-Allow-Private-Network:
true כדי לציין באופן מפורש שהוא מעניק גישה למשאב.
אנחנו מבקשים משוב
אם אתם מארחים אתר ברשת פרטית שמצפה לבקשות מרשתות ציבוריות, צוות Chrome ירצה לקבל מכם משוב ותרחישי שימוש. יש שתי דרכים שבהן תוכלו לעזור:
- עוברים אל
about://flags#block-insecure-private-network-requests, מפעילים את הדגל ובודקים אם האתר שולח בקשות למשאב הרשת הפרטי כצפוי. - אם תיתקלו בבעיות או אם יהיה לכם משוב, תוכלו לדווח על הבעיה בכתובת crbug.com ולהגדיר את הרכיב כ-
Blink>SecurityFeature>CORS>RFC1918.
דוגמה למשוב
הנתב האלחוטי שלנו משמש לאתר אדמין של אותה רשת פרטית, אבל דרך HTTP. אם נדרש HTTPS לאתרים שמוטמע בהם אתר האדמין, זה יהיה תוכן מעורב. האם כדאי להפעיל את HTTPS באתר האדמין ברשת סגורה?
זהו בדיוק סוג המשוב שאנחנו מחפשים ב-Chrome. אפשר לדווח על הבעיה עם התרחיש לדוגמה הספציפי שלך בכתובת crbug.com. אנחנו ב-Chrome נשמח לשמוע ממך.