निजी नेटवर्क ऐक्सेस: प्रीफ़्लाइट सुविधा शुरू की जा रही है

अपडेट

• 7 जुलाई, 2022: मौजूदा स्थिति अपडेट की गई और आईपी पता स्पेस की जानकारी जोड़ी गई.
• 27 अप्रैल, 2022: टाइमलाइन का एलान अपडेट किया गया.
• 7 मार्च, 2022: Chrome 98.

परिचय

Chrome, निजी नेटवर्क एंडपॉइंट को सार्वजनिक तौर पर सीधे ऐक्सेस करने की सुविधा बंद कर रहा है वेबसाइटों और निजी नेटवर्क का ऐक्सेस (पीएनए) स्पेसिफ़िकेशन.

Chrome, किसी सबरिसॉर्स के लिए निजी नेटवर्क अनुरोध से पहले, सीओआरएस प्रीफ़्लाइट अनुरोध भेजना शुरू कर देगा को लक्षित करें. यह प्रीफ़्लाइट अनुरोध होगा नया हेडर, Access-Control-Request-Private-Network: true और के रिस्पॉन्स में संबंधित हेडर होना चाहिए, Access-Control-Allow-Private-Network: true.

इसका मकसद उपयोगकर्ताओं को क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ) हमलों से बचाना है यह निजी नेटवर्क के राऊटर और अन्य डिवाइसों को टारगेट करता है. इन हमलों का असर लाखों उपयोगकर्ताओं पर पड़ा है, इससे हमलावर उन्हें नुकसान पहुंचाने वाले सर्वर पर रीडायरेक्ट कर सकते हैं.

रोल आउट प्लान

Chrome इस बदलाव को दो चरणों में रोल आउट करेगा, ताकि वेबसाइटों को सूचना देने का समय मिल सके और उसके हिसाब से बदलाव कर सकते हैं.

1. Chrome 104 में:

   • Chrome प्रयोग, निजी नेटवर्क से पहले प्रीफ़्लाइट अनुरोध भेजकर सबरिसॉर्स के अनुरोध शामिल हैं.
   • प्रीफ़्लाइट फ़ेल होने की वजह से, DevTools में सिर्फ़ चेतावनियां दिखती हैं. इसके अलावा, कोई दूसरी कार्रवाई नहीं होती का असर निजी नेटवर्क अनुरोधों पर पड़ रहा है.
   • Chrome, काम करने वाला डेटा इकट्ठा करके उन सबसे बड़े लोगों से संपर्क करता है जिन पर इस समस्या का असर पड़ा है वेबसाइटें.
   • हम उम्मीद करते हैं कि यह मौजूदा वेबसाइटों के साथ बड़े पैमाने पर काम करेगा.

2. Chrome 113 में सबसे जल्दी:

   • यह सिर्फ़ तब शुरू होगा, जब साथ काम करने वाले डेटा से पता चलेगा कि बदलाव काफ़ी सुरक्षित है और हम ज़रूरत पड़ने पर सीधे संपर्क करते हैं.
   • Chrome लागू करता है कि प्रीफ़्लाइट अनुरोध पूरे होने चाहिए, नहीं तो काम नहीं करेंगे अनुरोध.
   • सुविधा को बंद करने का ट्रायल इस तारीख से शुरू होगा: साथ ही, इस चरण से प्रभावित वेबसाइटों को समय एक्सटेंशन. मुफ़्त में आज़माने की अवधि कम से कम छह महीने तक रहेगी.

प्राइवेट नेटवर्क ऐक्सेस (पीएनए) क्या है

निजी नेटवर्क का ऐक्सेस (पहले इसे CORS-RFC1918 के नाम से जाना जाता था) सर्वर को निजी रूप से अनुरोध भेजने की वेबसाइटों की क्षमता को प्रतिबंधित करता है नेटवर्क.

Chrome ने पहले ही इस स्पेसिफ़िकेशन के कुछ हिस्से लागू कर दिए हैं: Chrome 96 तक, सिर्फ़ सुरक्षित कॉन्टेक्स्ट को निजी नेटवर्क अनुरोध करने की अनुमति है. हमारी ज़्यादा जानकारी के लिए, पिछली ब्लॉग पोस्ट देखें.

इस स्पेसिफ़िकेशन में क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) भी शामिल है ताकि वेबसाइटों को अब सर्वर से अनुमति के लिए साफ़ तौर पर अनुरोध करना पड़े निजी नेटवर्क पर पब्लिश किया जा सकता है.

PNA, आईपी पतों की कैटगरी कैसे तय करता है और निजी नेटवर्क की पहचान कैसे करता है

आईपी पतों को तीन आईपी पते के स्पेस में बांटा गया है: - public - private - local

लोकल आईपी पता स्पेस में ऐसे आईपी पते होते हैं जो या तो IPv4 होते हैं लूपबैक पते (127.0.0.0/8), RFC1122 के सेक्शन 3.2.1.3 में बताए गए हैं या आईपीवी6 लूपबैक पते (::1/128), RFC4291 के सेक्शन 2.5.3 में बताए गए हैं.

निजी आईपी पता स्पेस में ऐसे आईपी पते होते हैं जिनका सिर्फ़ मतलब होता है मौजूदा नेटवर्क में शामिल हैं. इसमें 10.0.0.0/8, 172.16.0.0/12 और RFC1918 में 192.168.0.0/16 के बारे में बताया गया है, RFC3927 में, लिंक के लोकल पते 169.254.0.0/16 के बारे में बताया गया है, RFC4193 में बताए गए यूनीक लोकल आईपीवी6 यूनिकास्ट पते fc00::/7, लिंक-लोकल IPv6 यूनिकास्ट पते fe80::/10 के बारे में RFC4291 के सेक्शन 2.5.6 में बताया गया है और IPv4-मैप किए गए IPv6 पते, जहां मैप किया गया IPv4 पता खुद निजी होता है.

सार्वजनिक आईपी पते वाले स्पेस में, ऐसे सभी पते शामिल होते हैं जिनके बारे में पहले नहीं बताया गया है.

लोकल आईपी पते को ऐसे निजी आईपी पते से ज़्यादा निजी माना जाता है जो किसी सार्वजनिक आईपी पते के मुकाबले, ज़्यादा निजी माना जाता है.

सुझाव, शिकायत या राय: निजी नेटवर्क के लिए सीओआरएस (RFC1918) पर ज़्यादा जानें.

प्रीफ़्लाइट अनुरोध

बैकग्राउंड

प्रीफ़्लाइट अनुरोध एक तरह का तरीका है. इसे इस्तेमाल किए जाने वाले क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) स्टैंडर्ड की मदद से बनाया जाता है किसी टारगेट वेबसाइट को एचटीटीपी अनुरोध भेजने से पहले उससे अनुमति का अनुरोध करने के लिए इस्तेमाल न करें. इससे पक्का होता है कि टारगेट सर्वर, सीओआरएस प्रोटोकॉल का इस्तेमाल किया जा सकता है और सीएसआरएफ हमलों के खतरे को काफ़ी कम किया जा सकता है.

अनुमति का अनुरोध, OPTIONS एचटीटीपी अनुरोध के तौर पर भेजा जाता है. इसमें खास सीओआरएस अनुरोध हेडर शामिल होते हैं जिसमें आने वाले एचटीटीपी अनुरोध के बारे में बताया गया है. रिस्पॉन्स में खास सीओआरएस रिस्पॉन्स हेडर शामिल होने चाहिए आने वाले अनुरोध पर साफ़ तौर पर सहमति देना.

निजी नेटवर्क के ऐक्सेस में नया क्या है

प्रीफ़्लाइट अनुरोधों के लिए अनुरोध और रिस्पॉन्स हेडर का एक नया जोड़ा लॉन्च किया गया है:

• Access-Control-Request-Private-Network: true सभी PNA प्रीफ़्लाइट अनुरोधों पर सेट है
• सभी PNA प्रीफ़्लाइट जवाबों के लिए Access-Control-Allow-Private-Network: true सेट होना चाहिए

पीएनए के लिए प्रीफ़्लाइट अनुरोध, सभी निजी नेटवर्क अनुरोधों के लिए भेजे जाते हैं, फिर चाहे अनुरोध का तरीका कुछ भी हो और mode का इस्तेमाल करें. उन्हें भेज दिया गया है cors मोड, no-cors और अन्य सभी मोड में अनुरोधों से आगे हैं. यह इसकी वजह यह है कि निजी नेटवर्क के सभी अनुरोध सीएसआरएफ हमलों के लिए इस्तेमाल किए जा सकते हैं. भले ही, अनुरोध मोड और जवाब का कॉन्टेंट बनाया गया हो या नहीं उपलब्ध कराता है.

पीएनए के लिए प्रीफ़्लाइट अनुरोध, उसी ऑरिजिन वाले अनुरोधों के लिए भी भेजे जाते हैं, अगर टारगेट आईपी पता, शुरू करने वाले की तुलना में ज़्यादा निजी होता है. यह सामान्य से अलग है सीओआरएस, जहां प्रीफ़्लाइट अनुरोध सिर्फ़ क्रॉस-ऑरिजिन अनुरोधों के लिए होते हैं. प्रीफ़्लाइट एक ही ऑरिजिन के अनुरोधों के लिए किए जाने वाले अनुरोध, डीएनएस को रीबाइंडिंग करने से जुड़े हमले.

उदाहरण

दिखने वाला व्यवहार, उपयोगकर्ता की अनुरोध का मोड.

नो-सीओआरएस मोड

https://foo.example/index.html एम्बेड कहें <img src="https://bar.example/cat.gif" alt="dancing cat"/>, और bar.example का रिज़ॉल्यूशन 192.168.1.1 हो जाता है, जो कि एक निजी IP पता है आरएफ़सी 1918.

Chrome सबसे पहले प्रीफ़्लाइट अनुरोध भेजता है:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

इस अनुरोध को पूरा करने के लिए, सर्वर को इनके साथ जवाब देना होगा:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

इसके बाद, Chrome असली अनुरोध भेजेगा:

HTTP/1.1 GET /cat.gif
...

जिसके लिए सर्वर सामान्य रूप से जवाब दे सकता है.

सीओआरएस मोड

मान लें कि https://foo.example/index.html यह कोड चलाता है:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

फिर से, मान लें कि bar.example का मतलब 192.168.1.1 है.

Chrome सबसे पहले प्रीफ़्लाइट अनुरोध भेजता है:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

इस अनुरोध को पूरा करने के लिए, सर्वर को इनके साथ जवाब देना होगा:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

इसके बाद, Chrome असली अनुरोध भेजेगा:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

जिसके लिए सर्वर, सीओआरएस के सामान्य नियमों के मुताबिक जवाब दे सकता है:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

यह पता लगाने का तरीका कि आपकी वेबसाइट पर असर पड़ा है या नहीं

Chrome 104 में शुरू करते समय, अगर निजी नेटवर्क के अनुरोध का पता चलता है, तो प्रीफ़्लाइट अनुरोध से पहले उसे भेज दिया जाएगा. अगर यह प्रीफ़्लाइट अनुरोध फ़ेल होता है, तो फ़ाइनल अनुरोध अब भी भेजा जाएगा, लेकिन DevTools में एक चेतावनी दिखेगी समस्याओं के बारे में जानकारी देने वाले पैनल का इस्तेमाल करें.

प्रीफ़्लाइट के जिन अनुरोधों पर असर पड़ा है उन्हें नेटवर्क पैनल में भी देखा जा सकता है और उनका विश्लेषण किया जा सकता है:

अगर आपके अनुरोध ने बिना किसी नियमित सीओआरएस प्रीफ़्लाइट को ट्रिगर किया होता निजी नेटवर्क ऐक्सेस के नियमों का उल्लंघन करता है, तो दो प्रीफ़्लाइट ऐसा नेटवर्क पैनल जिसमें पहला पैनल हमेशा फ़ेल दिखता है. यह है जाना पड़ता है और आप इसे अनदेखा कर सकते हैं.

यह देखने के लिए कि प्रीफ़्लाइट सफल होने पर क्या होगा, आपके पास नीचे दिया गया कमांड लाइन आर्ग्युमेंट पास करें, Chrome 98 से शुरू करने के लिए:

--enable-features=PrivateNetworkAccessRespectPreflightResults

प्रीफ़्लाइट अनुरोध पूरा न होने पर, उसे फ़ेच नहीं किया जा सकेगा. इससे आपको अपने संगठन की ताकि यह जांच की जा सके कि आपकी वेबसाइट हमारे रोल आउट प्लान का दूसरा चरण तय किया जा सकता है. गड़बड़ियों का निदान यहां किया जा सकता है ठीक उसी तरह, जैसे ऊपर बताए गए DevTools पैनलों का इस्तेमाल करके चेतावनियों के लिए की जाती है.

अगर आपकी वेबसाइट पर असर पड़ा है, तो क्या करना चाहिए

Chrome 104 में यह बदलाव लॉन्च होने के बाद, वेबसाइट. हालांकि, हमारा सुझाव है कि आप ऐसे अनुरोध पाथ को अपडेट करें जिन पर असर पड़ा है यह पक्का करना होगा कि आपकी वेबसाइट उम्मीद के मुताबिक काम करती रहे.

आपके लिए दो समाधान उपलब्ध हैं:

1. सर्वर साइड पर प्रीफ़्लाइट अनुरोधों को मैनेज करना
2. एंटरप्राइज़ नीतियों के साथ पीएनए की जांच की सुविधा बंद करें

प्रीफ़्लाइट अनुरोधों को सर्वर-साइड मैनेज करना

PNA प्रीफ़्लाइट को हैंडल करने के लिए, किसी भी ऐसे फ़ेच के टारगेट सर्वर को अपडेट करें जिस पर असर पड़ा हो अनुरोध. सबसे पहले, स्टैंडर्ड सीओआरएस प्रीफ़्लाइट अनुरोधों के लिए, सहायता इस तरह लागू करें प्रभावित रास्ते. इसके बाद, दो नए रिस्पॉन्स हेडर के लिए सहायता जोड़ें.

जब आपके सर्वर को प्रीफ़्लाइट अनुरोध मिलता है (सीओआरएस के साथ OPTIONS अनुरोध हेडर), सर्वर को जांच करनी चाहिए कि Access-Control-Request-Private-Network: true हेडर. अगर यह हेडर कोई अनुरोध होने पर, सर्वर को Origin हेडर और के साथ कोई अन्य प्रासंगिक जानकारी (जैसे कि Access-Control-Request-Headers). इससे यह पक्का किया जा सकेगा कि अनुरोध सुरक्षित है. आम तौर पर, आपको अपने कंट्रोल में किसी एक ऑरिजिन का ऐक्सेस देना चाहिए.

जब आपका सर्वर अनुरोध की अनुमति दे दे, तो उसे जवाब देना चाहिए ज़रूरी सीओआरएस हेडर और नए पीएनए के साथ 204 No Content (या 200 OK) हेडर. इन हेडर में Access-Control-Allow-Origin और Access-Control-Allow-Private-Network: true और अन्य ज़रूरतों को पूरा करने के लिए.

ठोस स्थितियों के लिए उदाहरण देखें.

एंटरप्राइज़ नीतियों का इस्तेमाल करके, निजी नेटवर्क ऐक्सेस की जांच बंद करें

अगर आपके पास अपने उपयोगकर्ताओं पर एडमिन कंट्रोल है, तो 'निजी' को बंद किया जा सकता है नेटवर्क ऐक्सेस की जांच करने के लिए, इनमें से किसी नीति का इस्तेमाल किया जाता है:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

ज़्यादा जानकारी के लिए, Chrome की नीतियां मैनेज करने को समझना लेख पढ़ें.

हमें प्रतिक्रिया दें

अगर किसी निजी नेटवर्क वाली वेबसाइट को होस्ट किया जा रहा है, तो सार्वजनिक नेटवर्क पर, Chrome टीम आपके फ़ीडबैक और उपयोग के उदाहरणों में रुचि रखती है. crbug.com पर जाकर, Chromium में समस्या हल करें. इसके बाद, Blink>SecurityFeature>CORS>PrivateNetworkAccess के लिए कॉम्पोनेंट.

आगे क्या करना है

इसके बाद, Chrome निजी नेटवर्क ऐक्सेस जांच का दायरा बढ़ाएगा, ताकि वेब वर्कर: इनके अलावा, सेवा देने वाले लोग भी आपके साथ काम कर सकते हैं. फ़िलहाल, हम यह कोशिश कर रहे हैं कि में चेतावनी दिखानी होगी.

इसके बाद, Chrome नेविगेशन को कवर करने के लिए, निजी नेटवर्क ऐक्सेस से जुड़ी जांचों का दायरा बढ़ाएगा, इसमें iframe और पॉप-अप शामिल हैं. आने वाले समय में, हम Chrome 108 को पहले से इस्तेमाल करने पर काम कर रहे हैं चेतावनियां दिखाई जा रही हैं.

दोनों ही मामलों में, हम सोच-समझकर एक ही चरण में रोल आउट करने की कोशिश करेंगे. ताकि वेब डेवलपर को काम करने से जुड़े जोखिमों में बदलाव करने और उनका अनुमान लगाने का समय मिल सके.

स्वीकार की गई

इस पर मार्क ओल्सन की कवर फ़ोटो अनस्प्लैश.