צמצום הסיכונים שקשורים לחשיפה לא מכוונת של מכשירים ושרתים ברשת הפנימית של לקוח לאינטרנט הרחב.
אתרים זדוניים ששולחים בקשות למכשירים ולשרתים שמארחים ברשת פרטית הם איום כבר הרבה זמן. לדוגמה, תוקפים יכולים לשנות את ההגדרות של נתב אלחוטי כדי לאפשר התקפות מסוג Man-in-the-Middle. CORS-RFC1918 היא הצעה לחסימת בקשות כאלה כברירת מחדל בדפדפן, ולדרוש ממכשירים פנימיים להסכים לקבל בקשות מהאינטרנט הציבורי.
כדי להבין איך השינוי הזה משפיע על המערכת האקולוגית של האינטרנט, צוות Chrome מחפש משוב ממפתחים שיוצרים שרתים לרשתות פרטיות.
מה לא בסדר במצב הקיים?
הרבה שרתי אינטרנט פועלים ברשת פרטית – נתבים אלחוטיים, מדפסות, אתרי אינטראנט, שירותים ארגוניים ומכשירי אינטרנט של הדברים (IoT) הם רק חלק מהם. יכול להיות שסביבות כאלה נראות בטוחות יותר מאלה שחשופות לציבור, אבל תוקפים יכולים לנצל את השרתים האלה לרעה באמצעות דף אינטרנט כ-proxy. לדוגמה, אתרים זדוניים יכולים להטמיע כתובת URL, שכאשר הקורבן רק צופה בה (בדפדפן עם JavaScript), היא מנסה לשנות את הגדרות שרת ה-DNS בנתב הפס הרחב הביתי של הקורבן. סוג התקפה כזה נקרא Drive-By Pharming, והוא קרה בשנת 2014. יותר מ-300,000 נתבים אלחוטיים פגיעים נוצלו על ידי שינוי הגדרות ה-DNS שלהם, מה שאיפשר לתוקפים להפנות מחדש משתמשים לשרתים זדוניים.
CORS-RFC1918
כדי לצמצם את הסיכון למתקפות דומות, קהילת האינטרנט משיקה את CORS-RFC1918 – שיתוף משאבים בין מקורות (CORS) שמתמחה ברשתות פרטיות שמוגדרות ב-RFC1918.
דפדפנים שמטמיעים בדיקת CORS בודקים עם משאבי היעד אם אפשר לטעון אותם ממקור אחר. הדבר נעשה באמצעות כותרות נוספות בתוך שורה שמתארות את הגישה, או באמצעות מנגנון שנקרא בקשות קדם-הפעלה, בהתאם למורכבות. מידע נוסף על שיתוף משאבים בין מקורות (CORS)
עם CORS-RFC1918, הדפדפן יחסום כברירת מחדל טעינה של משאבים ברשת הפרטית, אלא אם השרת מאפשר זאת באופן מפורש באמצעות CORS ו-HTTPS. האתר ששולח בקשות למשאבים האלה צריך לשלוח כותרות CORS, והשרת צריך לציין באופן מפורש שהוא מקבל את בקשת ה-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) שמוגדר ב-RFC3927 של IPv4, הקידומת 'Unique Local Address' (fc00::/7) שמוגדרת בקטע 3 של RFC4193 של IPv6, או הקידומת 'link-local' (fe80::/10) שמוגדרת בקטע 2.5.6 של RFC4291 של IPv6.
רשת ציבורית כל השאר.
התוכניות של Chrome להפעלת CORS-RFC1918
Chrome מציג את CORS-RFC1918 בשני שלבים:
שלב 1: בקשות למשאבי רשת פרטית יותרו רק מדפי אינטרנט של HTTPS
ב-Chrome 87 נוסף דגל שמחייב אתרים ציבוריים ששולחים בקשות למשאבי רשת פרטית להשתמש ב-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 ולפרט את התרחיש הספציפי לשימוש. נשמח לשמוע מכם.