נדרש משוב: CORS לרשתות פרטיות (RFC1918)

הפחתת הסיכונים הכרוכים בחשיפה לא מכוונת של מכשירים ושרתים ברשת הפנימית של הלקוח לאינטרנט באופן כללי.

Eiji Kitamura

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

המפתחים של מכשירים או שרתים כאלה יתבקשו לבצע שתי פעולות:

  • ודא שהאתר ששולח בקשות לרשת פרטית מוצג על גבי HTTPS.
  • הגדרת התמיכה בשרת עבור CORS-RFC1918 ותגובה עם כותרות HTTP צפויות.

על אילו סוגי בקשות יושפעו?

הבקשות המושפעות כוללות:

  • בקשות מהרשת הציבורית לרשת פרטית
  • בקשות מרשת פרטית לרשת מקומית
  • בקשות מהרשת הציבורית לרשת מקומית

רשת פרטית יעד שמפנה למרחב כתובות פרטי שמוגדר בסעיף 3 של RFC1918 ב-IPv4, כתובת IPv6 הממופה לפי IPv4 שבה כתובת ה-IPv4 הממופה היא פרטית, או כתובת IPv6 מחוץ לרשתות המשנה ::1/128, 2000::/3 ו-ff00::/8.

רשת מקומית יעד שתואם למרחב "לולאות לאחור" (127.0.0.0/8) שהוגדר בסעיף 3.2.1.3 ב-RFC1122 של IPv4, המרחב "link-local" (169.254.0.0/16) המוגדר ב-RFC3927 של IPv4, בקידומת 'כתובת מקומית ייחודית' (fc00::/7) שמוגדרת בסעיף 3 ב-'כתובת RFC126} ב-RFC4193fe80::/10RFC4291

רשת ציבורית וכל השאר.

הקשר בין רשתות ציבוריות, פרטיות ומקומיות ב-CORS-RFC1918
הקשר בין רשתות ציבוריות, פרטיות ומקומיות ב-CORS-RFC1918.

התוכניות של Chrome להפעיל את CORS-RFC1918

Chrome מציג את CORS-RFC1918 בשני שלבים:

שלב 1: בקשות למשאבים של רשת פרטית מותרות רק מדפי אינטרנט מסוג HTTPS

ב-Chrome 87 נוסף סימון שמחייב אתרים ציבוריים ששולחים בקשות למשאבים של רשת פרטית להיות ב-HTTPS. אפשר להפעיל אותו בכתובת about://flags#block-insecure-private-network-requests. כשהדגל הזה מופעל, בקשות למשאב רשת פרטית מאתר HTTP ייחסמו.

החל מגרסה 88 של Chrome, שגיאות CORS-RFC1918 ידווחו כשגיאות מדיניות CORS במסוף.

שגיאות CORS-RFC1918 ידווחו כשגיאות מדיניות CORS במסוף.
שגיאות CORS-RFC1918 ידווחו כשגיאות CORS במסוף.

בחלונית רשת בכלי הפיתוח ל-Chrome, ניתן להפעיל את תיבת הסימון בקשות חסומות כדי להתמקד בבקשות חסומות:

גם שגיאות CORS-RFC1918 ידווחו כשגיאות CORS בחלונית 'רשת'.
שגיאות CORS-RFC1918 ידווחו גם כשגיאות CORS בחלונית רשת.

בגרסה 87 של Chrome, שגיאות 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.

תמונה ראשית (Hero) של סטיבן פיליפס ב-UnFlood.