תאריך פרסום: 9 ביוני 2025
ב-Chrome מתווספת בקשה חדשה להרשאה לאתרים שמבצעים חיבורים לרשת המקומית של המשתמש, כחלק מטיוטת המפרט של גישה לרשת מקומית. המטרה היא להגן על המשתמשים מפני התקפות זיוף בקשות בין אתרים (CSRF) שמטרגטות נתבים ומכשירים אחרים ברשתות פרטיות, וכדי לצמצם את היכולת של אתרים להשתמש בבקשות האלה כדי ליצור טביעת אצבע של הרשת המקומית של המשתמש.
כדי להבין איך השינוי הזה משפיע על הסביבה העסקית של האינטרנט, צוות Chrome מחפש משוב ממפתחים שמפתחים אפליקציות אינטרנט שמסתמכות על חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש. החל מגרסה 138 של Chrome, אפשר להביע הסכמה להגבלות החדשות האלה על ידי מעבר אל chrome://flags/#local-network-access-check והגדרת הדגל ל'מופעל (חסימה)'.
מהי גישה לרשת המקומית?
ההרשאה גישה לרשת המקומית מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשת המקומית של המשתמש (כולל שרתים שפועלים באופן מקומי במחשב של המשתמש), ומחייבת את המשתמש להעניק הרשאה לאתר לפני שאפשר לשלוח בקשות כאלה. היכולת לבקש את ההרשאה הזו מוגבלת להקשרים מאובטחים.
לפלטפורמות רבות אחרות, כמו Android, iOS ו-MacOS, יש הרשאת גישה לרשת המקומית. לדוגמה, יכול להיות נתתם לאפליקציית Google Home הרשאה לגשת לרשת המקומית כשהגדרתם מכשירי Google TV ו-Chromecast חדשים.
אילו סוגי בקשות מושפעים?
בשלב הראשון של הגישה לרשתות מקומיות, אנחנו מגדירים 'בקשה לרשת מקומית' ככל בקשה מ הרשת הציבורית אל רשת מקומית או יעד לולאה חוזרת.
רשת מקומית היא כל יעד שמתבצעת לו פעולת ניתוח (resolve) למרחב הכתובות הפרטי שמוגדר בקטע 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.
רשת ציבורית היא כל יעד אחר.
מכיוון שהרשאת הגישה לרשת המקומית מוגבלת להקשרים מאובטחים, ויכול להיות שיהיה קשה להעביר מכשירים ברשת המקומית ל-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 ל'מופעל (חסימה)'. כך אפשר להפעיל את ההודעה לבקשת הרשאת גישה לרשת המקומית עבור בקשות שהופעלו באמצעות ממשק ה-API fetch() של JavaScript, טעינת משאבים משניים וניווט בפריימים משניים.
אתר הדגמה זמין בכתובת https://local-network-access-testing.glitch.me/ כדי להפעיל סוגים שונים של בקשות לרשת המקומית.
בעיות ומגבלות ידועות
- חלון הבקשה החדש להרשאה מוטמע כרגע רק ב-Chrome למחשב. אנחנו עובדים כרגע על העברה של התכונה ל-Chrome ל-Android. (הבעיה מתועדת בcrbug.com/400455013).
- החיבורים של WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834) ו-WebRTC (crbug.com/421223919) לרשת המקומית עדיין לא מוגבלים על ידי ההרשאה LNA.
- נכון לעכשיו, כדי לשלוח בקשות לרשת המקומית מ-Service Workers, צריך שהמקור של ה-Service Worker קיבל בעבר את ההרשאה 'גישה לרשת המקומית'.
- אם האפליקציה שולחת בקשות לרשת מקומית מ-service worker, בשלב הזה תצטרכו להפעיל בנפרד בקשה לרשת מקומית מהאפליקציה כדי להפעיל את הבקשה להרשאה. (אנחנו עובדים על דרך שבה העובדים יוכלו להפעיל את הודעה הבקשה להרשאה אם יש מסמך פעיל זמין – ראו crbug.com/404887282).
Chrome מגרסה 139 ואילך
אנחנו מתכוונים להשיק את הגישה לרשת המקומית בהקדם האפשרי. מכיוון שיכול להיות שלאתרים מסוימים יידרש זמן נוסף כדי לעדכן את ההערות לגבי גישה לרשת המקומית, נוסיף תקופת ניסיון למקורות כדי לאפשר לאתרים לבטל באופן זמני את ההסכמה לדרישות לגבי הקשרים מאובטחים לפני שנשלח את הגישה לרשת המקומית כברירת מחדל. כך המפתחים יוכלו למצוא נתיב העברה ברור יותר, במיוחד אם אתם מסתמכים על גישה למשאבים ברשת המקומית דרך HTTP (כי הבקשות האלה ייחסמו כתוכן מעורב אם הן יישלחו מדף HTTPS בדפדפנים שעדיין לא תומכים בפטור מהכלל לגבי תוכן מעורב בגישה לרשת המקומית).
בנוסף, נוסיף מדיניות ארגונית של Chrome לצורך בקרה על האתרים שיכולים לשלוח בקשות לרשת המקומית ועל האתרים שלא יכולים לעשות זאת (מתן או דחייה מראש של ההרשאה לאתרים האלה). כך, התקנות מנוהלות של Chrome, כמו התקנות בארגונים, יוכלו להימנע מהצגת האזהרה בתרחישי שימוש ידועים, או להמשיך לנעול את המערכת ולמנוע מאתרים לבקש את ההרשאה בכלל.
אנחנו מתכננים להמשיך לשלב את ההרשאה 'גישה לרשת המקומית' עם תכונות שונות שיכולות לשלוח בקשות לרשת המקומית. לדוגמה, בקרוב נשיק גישה לרשת המקומית לחיבורים של WebSockets, WebTransport ו-WebRTC.
נשתף מידע נוסף ככל שנתקרב לתאריך ההשקה המלאה של גישה לרשת המקומית ב-Chrome.
אנחנו מבקשים משוב
המשוב הקודם שקיבלנו על הפיתוח של Private Network Access עזר לנו מאוד להגיע לגישה החדשה שלנו להרשאות גישה לרשת המקומית. אנחנו רוצים להודות שוב לכל מי שהיה מעורב במהלך השנים.
אם אתם מפתחים או משתמשים באתר שמסתמך על חיבורים לרשת המקומית של המשתמש או לתוכנה שפועלת באופן מקומי במחשב של המשתמש, צוות Chrome ירצה לקבל מכם משוב ותרחישי שימוש. יש שתי דרכים שבהן תוכלו לעזור:
- עוברים אל
chrome://flags#local-network-access-check, מגדירים את הדגל ל-'מופעל (חסימת תגובה)' ובודקים אם האתר מפעיל בצורה תקינה את הבקשה החדשה להרשאה (ופועל כצפוי אחרי שמאשרים את ההרשאה). - אם תיתקלו בבעיות או אם יש לכם משוב, תוכלו לדווח על בעיה במערכת המעקב אחר בעיות ב-Chromium או במאגר GitHub של הסבר על LNA. נשמח לשמוע ממך על Chrome.