उपयोगकर्ताओं के लिए अपनी local network तक पहुँचने वाली साइटों को सीमित करने का प्रस्ताव

• Chrome security team ने वेबसाइटों की local network access समस्या को हल करने के लिए एक नया "Local Network Access permission" मॉडल प्रस्तावित किया है
• अभी public websites यूज़र के printer जैसे local network devices तक बिना अनुमति पहुँचने या उन पर हमला करने की कोशिश कर सकती हैं, लेकिन इस प्रस्ताव का लक्ष्य यूज़र की अनुमति के बिना local network requests को block करना है
• मौजूदा Private Network Access(PNA) से अलग, यह preflight की बजाय user permission consent पर आधारित है, जिससे यूज़र का control बढ़ता है और devices में बदलाव किए बिना सिर्फ site update से प्रतिक्रिया संभव है
• खास तौर पर, जब public site local IP, .local domain आदि पर fetch request भेजे, तो permission न होने पर browser यूज़र से स्पष्ट consent मांगेगा
• इस policy से security और privacy मजबूत होंगी, और IoT device setup जैसे वैध use cases यूज़र की अनुमति मिलने पर सामान्य रूप से काम करते रहेंगे

---

प्रस्ताव का अवलोकन और उद्देश्य

• Chrome Secure Web and Network team ने public websites द्वारा local network तक अनधिकृत पहुँच की समस्या हल करने के लिए 'Local Network Access' permission grant मॉडल का प्रारंभिक design draft जारी किया
• पहले, विज़िट की गई साइटें यूज़र के printer, router जैसे local network devices पर CSRF या अन्य attacks की कोशिश कर सकती थीं
• आगे से public IP → local IP जैसे address-space boundaries को पार करने वाले requests को browser रोकेगा, और site-wise स्पष्ट user permission मिलने पर ही उन्हें अनुमति देने का प्रस्ताव है

पृष्ठभूमि और अंतर

• मौजूदा Private Network Access(PNA) preflight (पूर्व request/response) आधारित है, और devices में भी बदलाव चाहिए होते हैं, इसलिए इसे लागू करना कठिन था
• यह नया प्रस्ताव सिर्फ user permission consent से काम कर सकता है, और केवल साइटों में छोटे बदलावों से लागू हो सकता है, इसलिए वास्तविक adoption और rollout आसान है

लक्ष्य और गैर-लक्ष्य

• लक्ष्य
  • drive-by web आधारित कमज़ोर devices और servers के दुरुपयोग को रोकना
  • केवल तब public websites को local devices से communicate करने देना, जब यूज़र ऐसा चाहता हो और अनुमति दे
• गैर-लक्ष्य
  • local devices की existing setup/control जैसी उचित user flows को पूरी तरह block करना उद्देश्य नहीं है
  • local network HTTPS समस्याएँ, जटिल certificate issuance आदि इस प्रस्ताव के दायरे से बाहर हैं

उपयोग के मामले

• 1: यदि सामान्य यूज़र नहीं चाहता, और example.com 192.168.0.1 आदि पर request भेजता है, तो browser अनुमति पूछेगा, और मना करने पर request block हो जाएगी
• 2: IoT, router आदि device manufacturers के official web setup pages पहली बार access पर यूज़र से अनुमति लेकर communication की इजाज़त पा सकते हैं

विस्तृत डिज़ाइन

• address space separation:
  • IP network layers को loopback (केवल स्वयं के लिए), local (local network के भीतर), public (सभी के लिए सुलभ) इन तीन स्तरों में वर्गीकृत किया जाता है
  • इसमें .local domains, RFC1918/4193 के private IPs, RFC6762 के link-local names जैसे local network पहचान मानदंड शामिल हैं
• local network requests: public→local, public→loopback, local→loopback जैसे अधिक public address space से internal network तक पहुँचने पर permission की आवश्यकता होगी
  • public network से local/loopback network तक के requests, और local से loopback तक के requests को local network requests माना जाएगा
  • अपवाद: local→local, loopback→किसी भी address जैसे cases restriction के दायरे में नहीं आते
• permission prompt:
  • जब कोई साइट local network पर request भेजे और permission न हो, तो browser यूज़र से अनुमति माँगने वाला prompt दिखाएगा
  • अस्वीकार करने पर request block होगी, स्वीकार करने पर request आगे बढ़ेगी
• fetch API integration: fetch call में targetAddressSpace: "local" जैसे options स्पष्ट रूप से दिए जा सकेंगे
  • Fetch spec DNS resolution के बिना केवल simple connection को define करता है, इसलिए नए connection में यह तय किया जाएगा कि request local network request है या नहीं
  • केवल secure contexts में local network requests की अनुमति होगी; permission न होने पर prompt, और permission मिलने पर request allowed होगी
  • fetch() के options में targetAddressSpace parameter जोड़कर developers destination address space को स्पष्ट रूप से निर्दिष्ट कर सकेंगे
    • ex) fetch("http://router.com/ping";, { targetAddressSpace: "local" })
  • यदि वास्तविक connected address option में दिए गए space से मेल न खाए, तो request fail होगी ताकि mixed content bypass रोका जा सके
• HTML, WebRTC, ServiceWorker आदि पर भी वही policy लागू होगी
  • HTML documents/workers में address space value जोड़कर origin-based space को track किया जाएगा
  • WebRTC में ICE Agent candidate जोड़ते समय local/loopback addresses के लिए permission prompt इस्तेमाल होगा
  • permissions को Permissions API से जोड़ा जाएगा, ताकि sites current permission state query कर सकें
  • default रूप से केवल top-level document से local network access होगी; जरूरत पड़ने पर Permissions Policy delegation से subframes को permission दी जा सकेगी
• mixed content (HTTP/HTTPS) समस्या:
  • insecure contexts से local network access के प्रयास, HTTP आधारित subresource loading, mixed content blocking लागू होने जैसे scenarios शामिल हैं
  • private IP literals, .local domains, targetAddressSpace वाले requests के लिए mixed content upgrade और blocking steps को छोड़कर, बाद के connection चरण में permission न रखने वाले origin को block किया जाएगा
• काम करने के उदाहरण
  • अप्रत्याशित local network access होने पर, यूज़र permission deny करके अनधिकृत requests रोक सकता है
  • device manufacturer द्वारा चलाए जाने वाले control page के मामले में, उचित property (जैसे targetAddressSpace="local") के साथ call करने पर यूज़र की सहमति मिलने से यह पहले की तरह काम कर सकता है

विकल्प और चर्चा

• PNA तरीका:
  • मौजूदा PNA में CORS preflight आवश्यक था, लेकिन वास्तविक deployment और rollout कठिन था
  • कुछ हिस्सों में permission prompt और mixed content exceptions की अनुमति जैसे उपाय प्रस्तावित किए गए
  • DNS समस्याएँ, devices में spec support की कमी आदि के कारण व्यावहारिक सीमाएँ मौजूद हैं
• सभी local network requests को block करना: यह सरल है, लेकिन इससे use cases टूट सकते हैं और bypass cost बढ़ सकती है, इसलिए यह व्यावहारिक नहीं माना गया
• मौजूदा स्थिति बनाए रखना: OS स्तर पर app-wise local network permissions का प्रबंधन शुरू होने से browser स्तर पर भी प्रबंधन की आवश्यकता पर ज़ोर दिया गया
• mixed content के विकल्प:
  • "केवल secure local network subresources की अनुमति" जैसे तरीकों की security evaluation और implementation cost पर चर्चा हुई
  • response headers/meta tags से address space घोषित करने या HTML element attributes जोड़ने जैसे विकल्प भी चर्चा में हैं

अतिरिक्त बिंदु

• HTML subresources (iframe, img आदि) में भी address space attribute जोड़ने की संभावना पर चर्चा
• permission grant होने पर excessive permission transitivity जैसे मुद्दों पर शोध परिणामों का प्रतिबिंब
• main frame navigation के समय local network access सीमित करना या warning interstitial दिखाना
• local/loopback addresses पर जाने वाले सभी cross-origin requests को व्यापक रूप से local network requests मानने का विकल्प भी विचाराधीन है
• network-wise granular permissions पर शोध, और दूसरे network पर जाने (दूसरी जगह connect होने) पर दोबारा consent की आवश्यकता

security और privacy संबंधी विचार

• permission मिलने पर किसी site को यूज़र के पूरे network के devices तक खोज और access के विस्तारित अधिकार मिलने की चिंता है
• prompt स्वीकार करते समय यूज़र को अपने इरादे का स्पष्ट बोध होना चाहिए, और preflight आधारित मॉडल की तुलना में यहाँ अधिक direct control मिलता है
• पूर्व permission के बिना कोई भी local network request संभव नहीं होगी, जिससे privacy protection और मजबूत होगी

[GN⁺]

Hacker News राय

• जब मैंने इसे पहली बार देखा तो मुझे यह फीचर पसंद आया, क्योंकि यह विचार ही बेहद बेतुका और खतरनाक लगता है कि वेबसाइटें मनमाने लोकल IP, या किसी भी IP, पर HTTP requests भेज सकें। अगर इससे कुछ enterprise apps या integrations टूट भी जाएँ तो मुझे फर्क नहीं पड़ता। enterprise पक्ष इसे management tools से फिर enable कर सकता है, और सामान्य users इसे खुद setting में बदल सकते हैं। मेरे हिसाब से सिर्फ एक popup दिखा देना काफी है: "यह वेबसाइट लोकल डिवाइस को नियंत्रित करना चाहती है - अनुमति दें/अस्वीकार करें".

  • एक अलग नज़रिया यह है कि लोकल नेटवर्क डिवाइस पहले से ही CORS की वजह से मनमानी वेबसाइटों से कुछ हद तक सुरक्षित हैं। यह परफेक्ट नहीं है, लेकिन काफी असरदार है। समस्या यह है कि CORS पूरी तरह target server की सहमति पर निर्भर करता है। यानी server को specific headers के जरिए उस वेबसाइट को access देना पड़ता है। यह प्रस्ताव उस मॉडल को और सख्त करता है ताकि server और वेबसाइट दोनों communication चाहते हों तब भी user की स्पष्ट मंजूरी ज़रूरी हो। पहले माना जाता था कि server और वेबसाइट की आपसी सहमति काफी है, लेकिन हाल के Facebook जैसे मामलों में वेबसाइटों ने फ़ोन के अंदर apps तक चुपचाप पहुँच बनाई, जिससे यह सिद्धांत टूट गया। यानी अब वेबसाइट और लोकल नेटवर्क server user के हितों के खिलाफ भी साथ काम कर सकते हैं।

  • "सामान्य user popup में allow/deny चुन लेगा" वाली बात पर यह कहा गया कि MacOS अभी app-permission के रूप में ऐसा करता है, लेकिन ज़्यादातर users बिना सोचे-समझे 'Allow' दबा देते हैं। इसलिए site-permission कर देने से भी सतर्कता बहुत ज़्यादा नहीं बढ़ेगी।

  • यह समझ नहीं आता कि वेबसाइटों को लोकल नेटवर्क तक पहुँचने की ज़रूरत ही क्यों होनी चाहिए। यह सिर्फ एक बिल्कुल नया security threat model बनाता है। यह भी सवाल है कि क्या वास्तव में ऐसे cases हैं जहाँ इससे बेहतर कोई समाधान नहीं है।

• Apple, Microsoft, Google जैसी कंपनियाँ USB और Bluetooth के लिए भी ऐसा ही तरीका अपनाएँ, ऐसी इच्छा जताई गई। आजकल लगभग हर install होने वाला app Bluetooth access माँगता है, जो बहुत परेशान करता है। उम्मीद यह है कि app जिन Bluetooth device IDs तक पहुँच सकता है, उन्हें manifest में घोषित करे और OS access को सिर्फ उन्हीं devices तक सीमित कर दे। उदाहरण के लिए Bose app को सिर्फ Bose devices ही दिखने चाहिए। कुछ लोगों ने बताया कि उन्होंने app permissions देख कर install ही नहीं किया, या access deny किया। camera या GPS permissions की तरह device ID registration और user prompt बेहतर होगा। Bose के case में prefix bose.xxx रजिस्टर हो और manifest में सिर्फ bose.* access माँगा जाए, फिर OS वही rule लागू करे। यही तरह की ID scheme USB और लोकल नेटवर्क devices पर भी लागू की जा सकती है। इच्छा यह है कि OS apps को network, USB, और Bluetooth scan करने से रोके।

  • उम्मीद है कि कभी न कभी Apple apps को 'नकली permission allow' का विकल्प देगा। जैसे कोई app कहे कि उसे contacts list चाहिए, तो उसे असली जैसी दिखने वाली random list दे दी जाए। GPS के साथ भी कुछ ऐसा ही हो। किसी ने सुना कि WhatsApp में contacts share न करने पर contacts के नाम assign नहीं किए जा सकते।

  • Github की third-party app integration की तरह एक granular model बेहतर लगेगा: "ABC आपके repos देखना चाहता है। कौन-से repos share करने हैं?"

• एक राय यह भी थी कि Internet Explorer ने पहले zoning system से इस समस्या को हल किया था। अधिक जानकारी के लिए MS दस्तावेज़ देखें।

  • विडंबना यह है कि Chrome ने भी Windows पर आंशिक रूप से IE के zone security framework का उपयोग किया था, लेकिन इस पर लगभग कोई आधिकारिक documentation नहीं थी।

  • यह बात हैरान करती है कि इसका कोई आधुनिक विकल्प मौजूद नहीं है। लोकल नेटवर्क access भी camera और microphone की तरह एक खास permission के जरिए ही मिलना चाहिए।

• यह विश्वास करना मुश्किल है कि web browsers ने default रूप से ऐसी चीज़ की अनुमति दी। अगर कोई public website चुपके से पूरे file system तक पहुँच सकती, तो यह भयानक security flaw माना जाता। लेकिन लोकल नेटवर्क services के मामले में वही काम XHR से किया जा सकता है, और सुरक्षा पूरी तरह server configuration पर छोड़ दी जाती है। अगर आप developer हैं और अपने dev PC पर testing के लिए कोई internal web app चला रहे हैं, जिसकी security बहुत ढीली है या है ही नहीं, तो facebook.com, google.com जैसी sites वहाँ तक सीधी पहुँच बना सकती हैं। घर पर भी बहुत लोग router firewall पर भरोसा करके बिना authentication services चलाते हैं, और यह भरोसा नहीं कि सबने CORS सही से configure किया होगा।

  • क्या सच में सब लोगों ने CORS सही से configure किया होगा? इस पर गहरी शंका जताई गई, और कहा गया कि व्यवहार में यह संख्या लगभग 0% के करीब होगी।

• उम्मीद है कि यह प्रस्ताव Meta की उस तकनीक को रोकने में मदद करेगा जिसमें वह अपने SDK के जरिए native apps और websites के बीच localhost-आधारित trick से पहचान codes साझा करता है, खासकर Android पर। और पढ़ें

• यह कहा गया कि वेबसाइटों को लोकल नेटवर्क access की permission देना बहुत ही मोटा और बेवजह अत्यधिक व्यापक अधिकार है। जिन साइटों को वास्तव में ऐसी permission चाहिए, उनमें से अधिकांश को सिर्फ एक ही लोकल server तक पहुँच चाहिए होती है। सब कुछ लोकल पर allow करना least privilege principle का उल्लंघन है। अधिकतर users को यह भी नहीं पता होता कि localhost या उनके network पर क्या चल रहा है, इसलिए वे असली जोखिम समझ ही नहीं पाते।

  • ज़्यादातर लोगों को यह नहीं पता होता कि localhost या network पर क्या चल रहा है, इसलिए अगर browser कहे कि http://localhost:3146 या http://localhost:8089 तक पहुँच की अनुमति दें, तो वे यह भी नहीं समझ पाएँगे कि इसका मतलब क्या है। तकनीकी jargon की बजाय "यह साइट लोकल नेटवर्क resources तक पहुँचने की कोशिश कर रही है" जैसी सीधी भाषा users के लिए बेहतर होगी।

  • इसे सही तरह implement करने के लिए लगभग browser-level firewall जैसी व्यवस्था चाहिए। ऐसा API उपयोगी होगा जिसमें CIDR, port आदि को बारीकी से नियंत्रित किया जा सके। browser extensions भी ऐसा firewall API इस्तेमाल कर सकें, या default UI में specific machine, जैसे router, LAN, VPN, या Windows private network जैसी अलग-अलग सीमाओं को स्पष्ट दिखाकर उनके लिए अलग access permissions माँगी जा सकें।

• पहले NPAPI plugin के खत्म होने के बाद कई public websites के लिए लोकल software के साथ integrate करने का एकमात्र रास्ता localhost पर HTTP server चलाना रह गया। अगर अब इस usability को भी जटिल बना दिया गया, तो यह बेहद असुविधाजनक हो जाएगा। राय यह थी कि browser vendors को NPAPI के बाद इसका कोई replacement तैयार करना चाहिए था, लेकिन अब शायद बहुत देर हो चुकी है।

  • ज़्यादातर software OS स्तर पर protocol handler register करते हैं। जैसे वेबसाइट zoommtg:// जैसा link देती है और browser उसे Zoom जैसे app के साथ खोल देता है। Jupyter Notebook जैसे use cases, जो cross-origin requests के बिना लोकल पर ही चलते हैं, प्रभावित नहीं होंगे। OAuth2 login के बाद localhost URL पर redirect करना भी सिर्फ redirect है, इसलिए शायद समस्या नहीं होगी।

  • एक राय यह भी थी कि अगर लोकल apps के साथ HTTP server के जरिए communication वाला यह मॉडल पूरी तरह खत्म हो जाए, तो वह और भी बेहतर होगा, क्योंकि यह लंबे समय से security vulnerabilities का स्रोत रहा है।

  • Mozilla Native messaging जैसी तकनीक पहले से मौजूद है। इसमें extension install करनी पड़ती है, लेकिन NPAPI की तुलना में यह अधिक उचित तरीका माना गया।

  • अगर लोकल software 'pull' मॉडल में काम करे, यानी app समय-समय पर बाहर request भेजे, तो अलग server चलाने की ज़रूरत ही नहीं होगी। साथ ही वेबसाइटें किसी के लोकल नेटवर्क में मनमाने scan भी नहीं कर पाएँगी, जो अतिरिक्त लाभ है।

• JavaScript में बिना cors option के fetch या POST request भेजने पर CORS सिर्फ response को पढ़ने से रोकता है, request भेजने से नहीं। यानी browser request फिर भी भेज देता है। अगर कोई लोकल app server-side proxy से CORS headers जोड़ दे, तो कोई भी site JS fetch/XMLHttpRequest से उसे access कर सकती है। extensions headers बदलकर CORS bypass भी कर सकती हैं। headers छेड़कर ऐसा bypass बहुत आसान है, जबकि CSP (Content Security Policy) को bypass करना वास्तव में बहुत कठिन, लगभग असंभव है। Facebook app अभी भी अपना खुद का cors proxy server चलाकर ऐसा setup इस्तेमाल करता है। WebSocket भी मौजूद है, इसलिए Chrome में localhost blocking flag होने पर भी खास फायदा नहीं। localhost को पूरी तरह block करना उल्टा नुकसानदेह होगा, क्योंकि बहुत से users self-hosted bookmarks, notes, password managers जैसी चीज़ों के लिए लोकल server इस्तेमाल करते हैं।

• IPv6 environment में समस्या आने की आशंका जताई गई। सवाल उठा कि क्या वास्तव में यह पहचानने का कोई तरीका है कि IPv6 address आंशिक रूप से लोकल है या नहीं। अगर नहीं, तो IPv6-only networks में यह प्रस्ताव समस्या पैदा करेगा। किसी ने IoT apps में यह समस्या झेली, और चूँकि IPv6 address के लोकल होने का पता लगाना कठिन था, इसलिए उसने IPv6 traffic को IPv4 local पर redirect करना चुना। IPv6 link-local addresses भी सामान्य apps के लिए लगभग बेकार थे। .local domain को लोकल server मानने का मामला भी पेचीदा है, क्योंकि हर OS इसे अलग तरह से समझता है। उदाहरण के लिए Raspberry Pi OS में some_address mDNS से resolve हो जाता है, लेकिन someaddress.local नहीं; जबकि Ubuntu 24.04 में someaddress.local चलता है और someaddress नहीं। someaddress.local. भी काम नहीं करता। अंत में यह शिकायत भी आई कि लोकल नेटवर्क addresses के लिए private certificates का उपयोग नहीं हो पाता, इसलिए "लोकल address पर https restriction" वाली समस्या का समाधान भी ज़रूरी है।

  • जवाब में कहा गया कि IPv6 में अब भी 'routable' होने की अवधारणा है, इसलिए तार्किक रूप से routing table के स्तर पर site-local जैसी परिभाषा की जा सकती है। पुराने IPv4 में दूसरा octet site और तीसरा octet VLAN के लिए होता था, जबकि IPv6 में विकल्प ज़्यादा हैं। सभी IPv6 devices के पास link-local address होता है, जो लोकल VLAN को दर्शाता है। .local Apple, DNS आदि के name-to-address mapping से जुड़ा शब्द है, IP address से सीधा संबंध नहीं। लोकल नेटवर्क में https certificates भी Let's Encrypt के DNS-01 validation, CNAME आदि के जरिए संभव हैं। यह काफ़ी झंझटी है, लेकिन मुफ़्त तरीका मौजूद है, और acme.sh जैसे tools की भी सिफारिश की गई। साथ ही कहा गया कि IPv4, IPv6, DNS, mDNS, Bonjour जैसी अवधारणाओं को अधिक स्पष्ट रूप से समझना चाहिए। किसी ने पुराने समय को याद किया जब packet capture तक paid हुआ करता था, और कहा कि अब हालात पहले से बेहतर हैं।

  • एक और टिप्पणी में साफ़ कहा गया कि endpoint स्तर पर यह पहचानने का कोई तरीका नहीं कि IPv6 address "लोकल" है या नहीं, क्योंकि IPv6 का मूल सिद्धांत global routing है। लेख में Google ने भी पहले "local" के अर्थ पर चर्चा की और बीच में 'private' की परिभाषा की ओर मुड़ गया, जिससे भ्रम पैदा हुआ। HTTP extension के जरिए CIDR-आधारित non-standard security boundary बनाना बेतुका तरीका बताया गया। राय यह थी कि apps को public services मानकर ही उनका security model डिज़ाइन करना चाहिए। .local mDNS spec में है, लेकिन व्यवहार में अक्सर नज़रअंदाज़ किया जाता है।

• इस तरह की व्यवस्था जल्दी लागू हो, ऐसी सच्ची इच्छा जताई गई, खासकर यह उम्मीद कि HTTPS domains से HTTP local sites तक पहुँचने का कोई फीचर हो। smart home, media, और entertainment में इसके कई अच्छे use cases बताए गए।