सुझाव चाहिए: निजी नेटवर्क के सीओआरएस (RFC1918)

इससे, क्लाइंट के इंटरनल नेटवर्क पर मौजूद डिवाइसों और सर्वर को वेब पर अनजाने में दिखने से जुड़े जोखिमों को कम किया जा सकता है.

निजी नेटवर्क पर होस्ट किए गए डिवाइसों और सर्वर से अनुरोध करने वाली नुकसान पहुंचाने वाली वेबसाइटें, लंबे समय से एक खतरा बनी हुई हैं. उदाहरण के लिए, हमलावर वायरलेस राउटर के कॉन्फ़िगरेशन में बदलाव करके, Man-in-the-Middle हमले कर सकते हैं. CORS-RFC1918 एक ऐसा प्रस्ताव है जिसके तहत, ब्राउज़र पर इस तरह के अनुरोधों को डिफ़ॉल्ट रूप से ब्लॉक किया जाता है. साथ ही, इंटरनल डिवाइसों को सार्वजनिक इंटरनेट से किए गए अनुरोधों के लिए ऑप्ट-इन करना ज़रूरी होता है.

इस बदलाव से वेब इकोसिस्टम पर क्या असर पड़ता है, यह समझने के लिए Chrome टीम, उन डेवलपर से सुझाव/राय मांग रही है जो निजी नेटवर्क के लिए सर्वर बनाते हैं.

मौजूदा स्थिति में क्या समस्या है?

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

CORS-RFC1918

इस तरह के हमलों के खतरे को कम करने के लिए, वेब कम्यूनिटी CORS-RFC1918क्रॉस ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) लेकर आ रही है. यह RFC1918 में तय किए गए निजी नेटवर्क के लिए खास तौर पर बनाया गया है.

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

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

ऐसे डिवाइसों या सर्वर के डेवलपर से दो काम करने के लिए कहा जाएगा:

  • पक्का करें कि निजी नेटवर्क से अनुरोध करने वाली वेबसाइट, एचटीटीपीएस पर काम करती हो.
  • सीओआरएस-RFC1918 के लिए सर्वर सपोर्ट सेट अप करें और अनुमानित एचटीटीपी हेडर के साथ जवाब दें.

किन तरह के अनुरोधों पर असर पड़ा है?

इन अनुरोधों पर असर पड़ा है:

  • सार्वजनिक नेटवर्क से किसी निजी नेटवर्क के लिए किए गए अनुरोध
  • किसी प्राइवेट नेटवर्क से लोकल नेटवर्क के लिए अनुरोध
  • पब्लिक नेटवर्क से लोकल नेटवर्क के लिए किए गए अनुरोध

निजी नेटवर्क ऐसा डेस्टिनेशन जो IPv4 में RFC1918 के सेक्शन 3 में तय किए गए निजी पते के स्पेस में रिज़ॉल्व होता है. इसके अलावा, यह IPv4-मैप किया गया IPv6 पता भी हो सकता है, जहां मैप किया गया IPv4 पता निजी होता है. यह ::1/128, 2000::/3, और ff00::/8 सबनेट के बाहर का IPv6 पता भी हो सकता है.

लोकल नेटवर्क यह एक ऐसा डेस्टिनेशन होता है जो IPv4 के RFC1122 के सेक्शन 3.2.1.3 में बताए गए "लूपबैक" स्पेस (127.0.0.0/8), IPv4 के RFC3927 में बताए गए "लिंक-लोकल" स्पेस (169.254.0.0/16), IPv6 के RFC4193 के सेक्शन 3 में बताए गए "यूनीक लोकल अड्रेस" प्रीफ़िक्स (fc00::/7) या IPv6 के RFC4291 के सेक्शन 2.5.6 में बताए गए "लिंक-लोकल" प्रीफ़िक्स (fe80::/10) पर रीडायरेक्ट करता है.

सार्वजनिक नेटवर्क अन्य सभी नेटवर्क.

CORS-RFC1918 में सार्वजनिक, निजी, और स्थानीय नेटवर्क के बीच संबंध
CORS-RFC1918 में सार्वजनिक, निजी, और लोकल नेटवर्क के बीच संबंध.

Chrome की, CORS-RFC1918 को चालू करने की योजनाएं

Chrome, सीओआरएस-RFC1918 को दो चरणों में लागू कर रहा है:

पहला चरण: निजी नेटवर्क के संसाधनों के लिए अनुरोध सिर्फ़ एचटीटीपीएस वेब पेजों से किए जा सकेंगे

Chrome 87 में एक फ़्लैग जोड़ा गया है. इससे सार्वजनिक वेबसाइटों के लिए, निजी नेटवर्क संसाधनों से अनुरोध करने पर एचटीटीपीएस का इस्तेमाल करना ज़रूरी हो जाता है. इसे चालू करने के लिए, about://flags#block-insecure-private-network-requests पर जाएं. इस फ़्लैग को चालू करने पर, एचटीटीपी वेबसाइट से निजी नेटवर्क संसाधन के लिए किए गए सभी अनुरोध ब्लॉक कर दिए जाएंगे.

Chrome 88 से, सीओआरएस-RFC1918 से जुड़ी गड़बड़ियों को कंसोल में सीओआरएस नीति से जुड़ी गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा.

कंसोल में, सीओआरएस-RFC1918 से जुड़ी गड़बड़ियों को सीओआरएस नीति से जुड़ी गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा.
CORS-RFC1918 से जुड़ी गड़बड़ियों को कंसोल में, सीओआरएस नीति से जुड़ी गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा.

Chrome DevTools के नेटवर्क पैनल में, ब्लॉक किए गए अनुरोध चेकबॉक्स को चालू किया जा सकता है. इससे, ब्लॉक किए गए अनुरोधों पर फ़ोकस किया जा सकता है:

CORS-RFC1918 से जुड़ी गड़बड़ियों को भी नेटवर्क पैनल में सीओआरएस से जुड़ी गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा.
CORS-RFC1918 से जुड़ी गड़बड़ियों को भी Network पैनल में, सीओआरएस से जुड़ी गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा.

Chrome 87 में, सीओआरएस-आरएफ़सी1918 से जुड़ी गड़बड़ियों की जानकारी सिर्फ़ DevTools कंसोल में ERR_INSECURE_PRIVATE_NETWORK_REQUEST के तौर पर दी जाती है.

इस टेस्ट वेबसाइट का इस्तेमाल करके, इसे खुद आज़माया जा सकता है.

दूसरा चरण: खास हेडर के साथ प्रीफ़्लाइट अनुरोध भेजना

आने वाले समय में, जब भी कोई सार्वजनिक वेबसाइट किसी निजी या स्थानीय नेटवर्क से संसाधन फ़ेच करने की कोशिश करेगी, तो Chrome असली अनुरोध से पहले प्रीफ़्लाइट अनुरोध भेजेगा.

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

सुझाव/राय मांगी गई

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

  • about://flags#block-insecure-private-network-requests पर जाएं. इसके बाद, फ़्लैग चालू करें और देखें कि आपकी वेबसाइट, उम्मीद के मुताबिक प्राइवेट नेटवर्क रिसॉर्स को अनुरोध भेज रही है या नहीं.
  • अगर आपको कोई समस्या दिखती है या आपको कोई सुझाव/राय देनी है या शिकायत करनी है, तो crbug.com पर जाकर समस्या की जानकारी दें. साथ ही, कॉम्पोनेंट को Blink>SecurityFeature>CORS>RFC1918 पर सेट करें.

सुझाव, शिकायत या राय का उदाहरण

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

Chrome को इसी तरह के सुझाव, शिकायत या राय की ज़रूरत है. कृपया crbug.com पर जाकर, इस्तेमाल के उदाहरण के साथ समस्या की शिकायत करें. Chrome को आपकी राय का इंतज़ार रहेगा.