इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

अपडेट

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

शुरुआती जानकारी

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

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

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

लॉन्च प्लान

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

Chrome 104 में:
- निजी नेटवर्क सबरिसॉर्स के अनुरोधों से पहले प्रीफ़्लाइट अनुरोध भेजकर Chrome प्रयोग करता है.
- प्रीफ़्लाइट के काम न करने की वजह से, सिर्फ़ DevTools में चेतावनियां दिखती हैं. इससे निजी नेटवर्क के अनुरोधों पर कोई असर नहीं पड़ता.
- Chrome, काम करने से जुड़ा डेटा इकट्ठा करता है और उन वेबसाइटों से संपर्क करता है जिन पर सबसे ज़्यादा असर हुआ है.
- हमें उम्मीद है कि यह मौजूदा वेबसाइटों के साथ ज़्यादा काम करेगा.
चेतावनी: Chrome 104 में, समय खत्म होने की अवधि 200 मिलीसेकंड तक सीमित रखी गई है. ऐसा उन वेबसाइटों पर असर को सीमित करने के लिए किया जाता है जो पहले से प्रीफ़्लाइट की सुविधा नहीं देती हैं. पाबंदी सिर्फ़ चेतावनी मोड में लागू होती है. एनफ़ोर्समेंट मोड चालू करने के बाद, chrome://flags में "निजी नेटवर्क ऐक्सेस प्रीफ़्लाइट के नतीजे का सम्मान करें" को "चालू है" पर स्विच करके, टाइम आउट की खास सीमा हटा दी जाएगी. यह डिफ़ॉल्ट सीमा पांच सेकंड की होगी.
Chrome 113 में:
- यह सिर्फ़ तब शुरू होगा, जब काम के डेटा से यह लगेगा कि बदलाव काफ़ी सुरक्षित है और ज़रूरत पड़ने पर हमने सीधे आपसे संपर्क किया है.
- Chrome लागू करता है कि प्रीफ़्लाइट अनुरोध पूरे होने चाहिए, नहीं तो अनुरोध पूरे नहीं होने चाहिए.
- इस चरण में जिन वेबसाइटों पर असर हुआ है उन्हें समयसीमा बढ़ाने का अनुरोध करने की अनुमति देने के लिए, रोक लगाने की सुविधा को बंद करने की सुविधा एक ही समय पर शुरू हो जाती है. मुफ़्त में आज़माने की अवधि कम से कम छह महीने तक रहेगी.

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

निजी नेटवर्क का ऐक्सेस (जिसे पहले सीओआरएस-आरएफ़सी1918 के नाम से जाना जाता था), निजी नेटवर्क पर सर्वर को अनुरोध भेजने की वेबसाइटों की क्षमता पर पाबंदी लगाता है.

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

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

मुख्य शब्द: निजी नेटवर्क के अनुरोध ऐसे अनुरोध होते हैं जिनके टारगेट सर्वर का आईपी पता, उस आईपी पते से ज़्यादा निजी होता है जिससे अनुरोध शुरू करने वाले को फ़ेच किया गया था. उदाहरण के लिए, किसी सार्वजनिक वेबसाइट (https://example.com) से किसी निजी वेबसाइट (http://router.local) को मिला अनुरोध या किसी निजी वेबसाइट से localhost को किया गया अनुरोध.

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

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

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

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

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

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

जब कोई ज़्यादा उपलब्ध नेटवर्क, कम उपलब्ध नेटवर्क को अनुरोध भेजता है, तो अनुरोध निजी होते हैं. — निजी नेटवर्क ऐक्सेस (CORS-RFC1918) में सार्वजनिक, निजी, और लोकल नेटवर्क के बीच संबंध

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

उदाहरण

मॉनिटर किया जाने वाला व्यवहार, अनुरोध के मोड के हिसाब से तय होता है.

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

मान लें कि https://foo.example/index.html एम्बेड करता है <img src="https://bar.example/cat.gif" alt="dancing cat"/> और bar.example, 192.168.1.1 को दिखाता है, जो आरएफ़सी 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

चेतावनी: सर्वर, Access-Control-Allow-Origin: * को सेट कर सकता है. हालांकि, ऐसा करना खतरनाक है और इसकी सलाह नहीं दी जाती है. निजी नेटवर्क के संसाधनों का ऐक्सेस शायद ही कभी सभी ऑरिजिन से होना चाहिए. इसलिए, इस तरह के हेडर को सेट करने से जुड़े जोखिमों के बारे में सोचें.

इसके बाद, 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 से जुड़ी समस्याओं वाले पैनल में चेतावनी दिखेगी.

Devtools की समस्याएं पैनल में, प्रीफ़्लाइट का अनुरोध पूरा न हो पाने की चेतावनी दिखती है. इसमें बताया गया है:
पक्का करें कि निजी नेटवर्क के अनुरोध सिर्फ़ उन संसाधनों के लिए किए गए हों जिन्हें अनुमति मिली है.
साथ ही, खास अनुरोध और उन संसाधनों की सूची दी गई है जिन पर इनका असर हुआ है.

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

localhost के लिए DevTools नेटवर्क पैनल में प्रीफ़्लाइट का अनुरोध पूरा न होने पर,
501 स्टेटस दिखता है.

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

DevTools नेटवर्क पैनल में सफल प्रीफ़्लाइट
से पहले, नकली प्रीफ़्लाइट अनुरोध प्रोसेस नहीं हो सका.

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

--enable-features=PrivateNetworkAccessRespectPreflightResults

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

अगर आपकी वेबसाइट पर इस समस्या का असर पड़ा है, तो क्या करें

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

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

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

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

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

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

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

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

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

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

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

अपने सुझाव दें

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

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

इसके बाद, Chrome उन वेब कर्मियों को कवर करने के लिए निजी नेटवर्क ऐक्सेस जांच का दायरा बढ़ाएगा जो काम करने के लिए खास तौर पर काम करने वाले वर्कर, शेयर किए गए वर्कर, और सर्विस वर्कर हैं. हम अभी Chrome 107 का इस्तेमाल करके चेतावनियां दिखाना शुरू करने की कोशिश कर रहे हैं.

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

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

स्वीकार हैं

Unsplash पर मार्क ओल्सन की कवर फ़ोटो.