תאריך פרסום: 9 ביוני 2025
ב-Chrome נוספת בקשת הרשאה חדשה לאתרים שמתחברים לרשת המקומית של המשתמש כחלק ממפרט הגישה לרשת המקומית. המטרה היא להגן על משתמשים מפני התקפות של זיוף בקשות חוצות אתרים (CSRF) שמכוונות לנתבים ולמכשירים אחרים ברשתות פרטיות, ולצמצם את היכולת של אתרים להשתמש בבקשות האלה כדי ליצור טביעת אצבע של הרשת המקומית של המשתמש.
כדי להבין איך השינוי הזה משפיע על המערכת האקולוגית של האינטרנט, צוות Chrome מחפש משוב ממפתחים שיוצרים אפליקציות אינטרנט שמסתמכות על יצירת חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש. החל מגרסה Chrome 138, אפשר להביע הסכמה להגבלות החדשות האלה על ידי מעבר אל chrome://flags/#local-network-access-check והגדרת התכונה הניסיונית ל'מופעלת (חסימה)'.
מהי גישה לרשת המקומית?
הגישה לרשת המקומית מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשת המקומית של המשתמש (כולל שרתים שפועלים באופן מקומי במחשב של המשתמש). כדי לשלוח בקשות כאלה, המשתמש צריך להעניק לאתר הרשאה. היכולת לבקש את ההרשאה הזו מוגבלת להקשרים מאובטחים.
בפלטפורמות רבות אחרות, כמו Android, iOS ו-MacOS, יש הרשאה לגישה לרשת מקומית. לדוגמה, יכול להיות שהענקתם את ההרשאה הזו לגישה לרשת המקומית לאפליקציית Google Home כשמגדירים מכשירי Google TV ו-Chromecast חדשים.
אילו סוגים של בקשות מושפעים?
בשלב הראשון של השקת הגישה לרשת המקומית, אנחנו מגדירים "בקשה לרשת המקומית" כבקשה מהרשת הציבורית אל רשת מקומית או אל יעד של משוב.
רשת מקומית היא כל יעד שמוביל לכתובות ששמורות לשימוש מקומי. לדוגמה, כתובות IPv4 פרטיות שמפורטות בסעיף 3 של RFC1918 (למשל, 192.168.0.0/16),
הקידומת של IPv4 'link-local' (169.254.0.0/16) שמוגדרת ב-RFC3927, הקידומת של IPv6 'Unique Local Address' (fc00::/7) שמוגדרת בסעיף 3 של RFC4193, הקידומת של IPv6 'link-local' (fe80::/10) שמוגדרת בסעיף 2.5.6 של RFC4291, או כתובת IPv6 שממופה ל-IPv4 (::ffff:0:0/96) שבה כתובת ה-IPv4 הממופה היא מקומית.
Loopback הוא כל יעד שמוביל למכונה המקומית (כלומר, ממשק 'loopback'), כמו קידומת ה-loopback של IPv4 (127.0.0.0/8) שמוגדרת בסעיף 3.2.1.3 של RFC1122, או ה-loopback של IPv6 (::1/128) שמוגדר בסעיף 2.5.3 של RFC4291.
מיפוי מלא של כתובות IP למרחבי כתובות מופיע בטבלה במפרט הגישה לרשת המקומית.
רשת ציבורית היא כל יעד אחר.
ההרשאה לגישה לרשת המקומית מוגבלת להקשרים מאובטחים, ויכול להיות שיהיה קשה להעביר מכשירים ברשת המקומית ל-HTTPS. לכן, בקשות גישה לרשת המקומית שמוגבלות בהרשאה יהיו פטורות מבדיקות של תוכן מעורב אם Chrome יודע שהבקשות יועברו לרשת המקומית לפני שהיעד יזוהה. מערכת Chrome יודעת שבקשה מיועדת לרשת המקומית אם:
- שם המארח של הבקשה הוא כתובת IP פרטית (למשל,
192.168.0.1). - שם המארח של הבקשה הוא דומיין
.local. - השיחה
fetch()מסומנת בהערה עם האפשרותtargetAddressSpace: "local".
// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");
// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");
// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");
// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
targetAddressSpace: "local",
});
מה עומד להשתנות ב-Chrome
Chrome 138
הגרסה הראשונית של הגישה לרשת המקומית מוכנה לבדיקה בהסכמה ב-Chrome 138. משתמשים יכולים להפעיל את הודעת הבקשה החדשה להרשאה על ידי הגדרת chrome://flags#local-network-access-check ל'מופעלת (חסימה)'. ההגדרה הזו תומכת בהצגת בקשה להרשאת גישה לרשת מקומית לבקשות שנוצרות באמצעות JavaScript fetch() API, טעינת משאבי משנה וניווט ב-iframe.
אתר הדגמה זמין בכתובת https://lna-testing.notyetsecure.com/ כדי להפעיל סוגים שונים של בקשות לרשת המקומית.
בעיות ידועות ומגבלות
- חיבורי WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) ו-WebRTC (crbug.com/421223919) לרשת המקומית עדיין לא מוגבלים על ידי הרשאת LNA.
- בקשות לרשת המקומית מ-Service Workers ומ-Shared Workers מחייבות שהמקור של ה-Worker קיבל בעבר הרשאת גישה לרשת המקומית.
- אם האפליקציה שלכם שולחת בקשות לרשת המקומית מ-service worker, תצטרכו להפעיל בנפרד בקשה לרשת המקומית מהאפליקציה כדי להפעיל את בקשת ההרשאה. (אנחנו עובדים על דרך שבה עובדים יוכלו להפעיל את ההודעה לבקשת הרשאה אם יש מסמך פעיל זמין – אפשר לעיין בכתובת crbug.com/404887282).
Chrome 139 ואילך
אנחנו מתכוונים להשיק את התכונה 'גישה לרשת המקומית' בהקדם האפשרי. אנחנו מבינים שחלק מהאתרים יצטרכו יותר זמן כדי להתעדכן בהערות לגבי גישה לרשת המקומית, ולכן נוסיף ניסיון מקור שיאפשר לאתרים לבטל באופן זמני את הדרישה להקשרים מאובטחים לפני שנשיק את הגישה לרשת המקומית כברירת מחדל. השינוי הזה אמור לספק למפתחים נתיב ברור יותר להעברה, במיוחד אם הם מסתמכים על גישה למשאבים ברשת המקומית באמצעות HTTP (כי בקשות כאלה ייחסמו כתוכן מעורב אם הן נשלחות מדף HTTPS בדפדפנים שעדיין לא תומכים בהחרגה של תוכן מעורב בגישה לרשת המקומית).
בנוסף, נוסיף מדיניות ארגונית של Chrome כדי לקבוע לאילו אתרים מותר לשלוח בקשות לרשת המקומית ולאילו אתרים אסור (הענקת הרשאה מראש לאתרים האלה או דחיית הרשאה מראש). כך אפשר יהיה למנוע הצגת האזהרה במקרים ידועים של שימוש מכוון, או לחלופין להגביל עוד יותר את האתרים ולמנוע מהם לבקש הרשאה בכלל.
אנחנו מתכננים להמשיך לשלב את הרשאת הגישה לרשת המקומית עם תכונות שונות שיכולות לשלוח בקשות לרשת המקומית. לדוגמה, אנחנו מתכננים להשיק בקרוב את התכונה 'גישה לרשת המקומית' לחיבורי WebSockets, WebTransport ו-WebRTC.
נשתף מידע נוסף ככל שנתקרב להשקה מלאה של גישה לרשת מקומית ב-Chrome.
נשמח לקבל משוב
המשוב הקודם שקיבלנו על פיתוח הגישה לרשת הפרטית היה בעל ערך רב, ועזר לנו להגיע לגישה החדשה שלנו להרשאת גישה לרשת המקומית. אנחנו רוצים להודות שוב לכל מי שהיה מעורב בפרויקט במהלך השנים.
אם אתם מפתחים אתרים שמסתמכים על יצירת חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש, או אם אתם משתמשים באתרים כאלה, צוות Chrome ישמח לקבל מכם משוב ותיאורי מקרה. יש שני דברים שאפשר לעשות כדי לעזור:
- עוברים אל
chrome://flags#local-network-access-check, מגדירים את הדגל לערך Enabled (Blocking) (מופעל (חסימה)) ובודקים אם באתר מופעלת באופן תקין בקשת ההרשאה החדשה (והאם האתר פועל כמצופה אחרי שנותנים את ההרשאה). - אם נתקלתם בבעיות או שיש לכם משוב, אתם יכולים לדווח על בעיה במעקב אחר בעיות ב-Chromium או במאגר GitHub של מפרט LNA. נשמח לשמוע ממך.