פורסם: 9 ביוני 2025
Chrome מוסיף הנחיה חדשה למתן הרשאה לאתרים שמתחברים לרשת המקומית של המשתמש כחלק ממפרט הגישה לרשת המקומית. המטרה היא להגן על משתמשים מפני התקפות של זיוף בקשות חוצות אתרים (CSRF) שמכוונות לנתבים ולמכשירים אחרים ברשתות פרטיות, וגם לצמצם את היכולת של אתרים להשתמש בבקשות האלה כדי ליצור טביעת אצבע של הרשת המקומית של המשתמש.
כדי להבין איך השינוי הזה משפיע על המערכת האקולוגית של האינטרנט, צוות Chrome מחפש משוב ממפתחים שיוצרים אפליקציות אינטרנט שמסתמכות על יצירת חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש. החל מגרסה Chrome 138, אפשר להביע הסכמה להגבלות החדשות האלה על ידי מעבר אל chrome://flags/#local-network-access-check והגדרת התכונה הניסיונית ל'מופעלת (חסימה)'.
מהי גישה לרשת המקומית?
הגישה לרשת המקומית מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשת המקומית של המשתמש (כולל שרתים שפועלים באופן מקומי במחשב של המשתמש). כדי לשלוח בקשות כאלה, המשתמש צריך להעניק לאתר הרשאה. היכולת לבקש את ההרשאה הזו מוגבלת להקשרים מאובטחים.
בפלטפורמות רבות אחרות, כמו Android, iOS ו-MacOS, יש הרשאה לגישה לרשת מקומית. לדוגמה, יכול להיות שהענקתם את ההרשאה הזו לגישה לרשת המקומית לאפליקציית Google Home כשמגדירים מכשירי Google TV ו-Chromecast חדשים.
אילו סוגים של בקשות מושפעים?
בשלב הראשון של השקת הגישה לרשת המקומית, אנחנו מגדירים "בקשה לרשת המקומית" ככל בקשה מ הרשת הציבורית אל רשת מקומית או אל יעד של משוב (loopback).
רשת מקומית היא כל יעד שמוגדר במרחב הכתובות הפרטיות שמוגדר בסעיף 3 של RFC1918 ב-IPv4 (למשל, 192.168.0.0/16), כתובת IPv6 שממופה ל-IPv4 שכתובת ה-IPv4 הממופה היא פרטית, או כתובת IPv6 מחוץ לרשתות המשנה ::1/128, 2000::/3 ו-ff00::/8.
Loopback הוא כל יעד שמפנה למרחב 'loopback' (127.0.0.0/8) שמוגדר בסעיף 3.2.1.3 של RFC1122 של IPv4, למרחב 'link-local' (169.254.0.0/16) שמוגדר ב-RFC3927 של IPv4, לקידומת 'Unique Local Address' (fcc00::/7) שמוגדרת בסעיף 3 של RFC4193 של IPv6, או לקידומת 'link-local' (fe80::/10) שמוגדרת בסעיף 2.5.6 של RFC4291 של IPv6.
מיפוי מלא של כתובות 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 כדי לקבוע לאילו אתרים מותר לשלוח בקשות לרשת המקומית ולאילו אתרים אסור (הענקת הרשאה מראש לאתרים האלה או דחיית הרשאה מראש). כך אפשר למנוע הצגת אזהרה במקרים ידועים של שימוש מכוון, או להגביל עוד יותר את האתרים ולמנוע מהם לבקש הרשאה בכלל. האפשרות הזו רלוונטית להתקנות מנוהלות של Chrome, כמו אלה שנעשות בהגדרות ארגוניות.
אנחנו מתכננים להמשיך לשלב את הרשאת הגישה לרשת המקומית עם תכונות שונות שיכולות לשלוח בקשות לרשת המקומית. לדוגמה, אנחנו מתכננים להשיק בקרוב את התכונה Local Network Access (גישה לרשת המקומית) לחיבורי WebSockets, WebTransport ו-WebRTC.
נשתף מידע נוסף ככל שנתקרב למועד ההשקה המלאה של התכונה 'גישה לרשת מקומית' ב-Chrome.
נשמח לקבל משוב
המשוב הקודם שקיבלנו על פיתוח הגישה לרשת הפרטית היה בעל ערך רב, ועזר לנו להגיע לגישה החדשה שלנו להרשאת גישה לרשת המקומית. אנחנו רוצים להודות שוב לכל מי שהיה מעורב בפרויקט במהלך השנים.
אם אתם מפתחים אתרים שמסתמכים על יצירת חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש, או אם אתם משתמשים באתרים כאלה, צוות Chrome ישמח לקבל מכם משוב ותיאורי מקרה. יש שני דברים שאתם יכולים לעשות כדי לעזור:
- עוברים אל
chrome://flags#local-network-access-check, מגדירים את הדגל לערך Enabled (Blocking) (מופעל (חסימה)) ובודקים אם באתר מופעלת באופן תקין בקשת ההרשאה החדשה (והאם האתר פועל כמצופה אחרי שנותנים את ההרשאה). - אם נתקלתם בבעיות או שיש לכם משוב, אתם יכולים לדווח על בעיה במעקב אחר בעיות ב-Chromium או במאגר GitHub של מפרט LNA. נשמח לשמוע ממך.