प्रश्न और दायरा (Scope)
डैशबोर्ड एक पब्लिक HTTPS ऑरिजिन से परोसा जाता है। यह कभी-कभी एक प्राइवेट एड्रेस पर प्रिंटर को और localhost पर एक हेल्पर को कॉल करता है; यह एक वेंडर iframe को भी एम्बेड करता है जिसे लोकल नेटवर्क तक नहीं पहुँचना चाहिए। बताएं कि ब्राउज़र पब्लिक, लोकल और लूपबैक एड्रेस स्पेस के बीच कैसे अंतर करता है, उपयोगकर्ता की अनुमति की आवश्यकता कब होती है, और अस्वीकृति (denial) के बाद पेज को कैसे रिकवर करना चाहिए।
एप्लिकेशन ऑथराइजेशन, CORS और डिवाइस ऑथेंटिकेशन को अलग-अलग लेयर्स के रूप में दायरे में रखें। ब्राउज़र की अनुमति उपयोगकर्ता-सहमति की एक सीमा है, इस बात का प्रमाण नहीं कि कोई प्रिंटर वर्तमान खाते का है। मान लें कि जब कोई ब्राउज़र Local Network Access को लागू नहीं करता है, तो प्रोडक्ट एक मैनुअल कॉन्फ़िगरेशन पाथ प्रदान कर सकता है।
इंटरव्यूअर क्या टेस्ट कर रहा है
मुख्य संकेत यह है कि क्या आप किसी प्राइवेट एंडपॉइंट को कॉल करने वाले पब्लिक पेज को एक सुरक्षा सीमा (security boundary) के रूप में पहचानते हैं। एक मजबूत उत्तर राउटर्स और प्रिंटर्स के खिलाफ CSRF-शैली के हमलों का नाम लेता है, फिर सुरक्षित संदर्भ (secure context), एड्रेस-स्पेस वर्गीकरण, अनुमति स्थिति (permission state) और एम्बेडेड कंटेंट के लिए एक अनुमति सूची (allowlist) के साथ फ़्लो को सीमित करता है।
इंटरव्यूअर यह भी जांचेगा कि क्या आप local-network को loopback-network के साथ भ्रमित करते हैं, या यह मान लेते हैं कि एक सफल CORS प्रीफ़्लाइट एक्सेस प्रदान करता है। एक अच्छा उत्तर पॉलिसी, अनुमति, मिक्स्ड कंटेंट, CORS और डिवाइस ऑथेंटिकेशन को अलग-अलग गेट्स के रूप में रखता है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या सभी टारगेट पहले से ज्ञात हैं, या उपयोगकर्ता मनमाने IP एड्रेस दर्ज कर सकते हैं? मनमाने स्कैनिंग के लिए एक अलग प्रोडक्ट बाउंड्री की आवश्यकता होती है और इसे एक सामान्य "कनेक्ट" बटन के पीछे नहीं छिपाया जाना चाहिए।
- क्या हेल्पर केवल
localhostपर है, या इसे किसी प्राइवेट सबनेट के माध्यम से एक्सेस किया जा सकता है? यह बदलता है कि लूपबैक अनुमति की आवश्यकता है या लोकल-नेटवर्क अनुमति की। - क्या कोई वेंडर iframe या नेस्टेड फ़्रेम अनुरोध कर सकता है? यदि हाँ, तो प्रत्येक फ़्रेम बाउंड्री को फीचर और उसके संभावित नेविगेशन ऑरिजिन को स्पष्ट रूप से डेलिगेट करना होगा।
- कौन से ब्राउज़र और एंटरप्राइज़ पॉलिसियों का समर्थन किया जाता है? रोलआउट का समय अलग-अलग होता है, इसलिए सुरक्षा को चुपचाप कमजोर करने के बजाय कम्पैटिबिलिटी पाथ अवलोकनीय (observable) होना चाहिए।
30-सेकंड का उत्तर फ़्रेमवर्क
"मैं डैशबोर्ड को HTTPS पर रखूँगा, प्रत्येक डेस्टिनेशन को पब्लिक, लोकल या लूपबैक के रूप में वर्गीकृत करूँगा, और आवश्यकता पड़ने पर केवल संबंधित ब्राउज़र अनुमति का अनुरोध करूँगा। रिस्पॉन्स पॉलिसी वेंडर iframe के लोकल एक्सेस को अस्वीकार करेगी; यदि किसी iframe को कनेक्ट होना ही है, तो इसकी allow सूची सटीक ऑरिजिन और सभी नेविगेशन टारगेट्स को निर्दिष्ट करेगी। मैं कार्रवाई से पहले अनुमति स्थिति की जाँच करूँगा, यह दिखाऊँगा कि एक्सेस की आवश्यकता क्यों है, मिक्स्ड-कंटेंट और CORS विफलताओं को अलग से संभालूँगा, और असमर्थित ब्राउज़रों के लिए एक मैनुअल सेटअप पाथ प्रदान करूँगा। टेस्ट यह सुनिश्चित करेंगे कि मनमाने होस्ट और प्रोडक्शन विज्ञापन फ़्रेम कभी भी लोकल-नेटवर्क अनुरोध को ट्रिगर न करें।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: ट्रस्ट बाउंड्री और एड्रेस स्पेस को परिभाषित करें
किसी पब्लिक वेबसाइट को उपयोगकर्ता के राउटर, प्रिंटर या डेवलपमेंट सर्विस पर चुपचाप स्टेट-चेंजिंग अनुरोध नहीं भेजने चाहिए। तीन डेस्टिनेशन वर्गों को मॉडल करें: पब्लिक एड्रेस विश्व स्तर पर पहुँच योग्य होते हैं, लोकल एड्रेस केवल उपयोगकर्ता के नेटवर्क पर पहुँच योग्य होते हैं, और लूपबैक एड्रेस उसी डिवाइस को लक्षित करते हैं। localhost प्रत्येक प्राइवेट सबनेट के समकक्ष नहीं है।
अनुरोध सूची (inventory) में fetch, सब-रिसोर्स लोड, WebSockets, WebTransport, WebRTC, सर्विस-वर्कर अनुरोध और फ़्रेम नेविगेशन शामिल होने चाहिए। एक लाइब्रेरी जो सॉकेट खोलती है, उसी सीमा को पार कर सकती है, भले ही एप्लिकेशन कोड में कोई सीधा fetch कॉल शामिल न हो।
चरण 2: एक सुरक्षित संदर्भ (secure context) और स्पष्ट अनुमति की आवश्यकता रखें
HTTPS टॉप-लेवल पेज का उपयोग करें। समर्थित ब्राउज़रों में, डिवाइस कार्रवाई का प्रयास करने से पहले प्रासंगिक अनुमति के बारे में क्वेरी करें:
const localState = await navigator.permissions.query({ name: "local-network" });
const loopbackState = await navigator.permissions.query({ name: "loopback-network" });granted, prompt, और denied को प्रोडक्ट स्टेट्स के रूप में मानें। कोई प्रॉम्प्ट ट्रिगर करने से पहले उद्देश्य स्पष्ट करें; अस्वीकृति पर, लूप में पुनः प्रयास करने के बजाय एक रिपेयर लिंक या मैनुअल सेटअप दिखाएं। इस फ़्लो के लिए HTTP पेज को असमर्थित माना जाना चाहिए, भले ही कोई टारगेट संयोग से जवाब दे दे।
चरण 3: एम्बेडेड दस्तावेज़ों को सीमित करें
टॉप-लेवल रिस्पॉन्स केवल उस फीचर और ऑरिजिन को डेलिगेट कर सकता है जिसे इसकी आवश्यकता है। वेंडर फ़्रेम को कोई लोकल-नेटवर्क क्षमता नहीं मिलती है:
Permissions-Policy: local-network=(self "https://dashboard.example"), loopback-network=(self "https://dashboard.example")यदि किसी विश्वसनीय सेटअप फ़्रेम को कनेक्ट होना है, तो संकीर्ण रूप से डेलिगेट करें:
<iframe src="https://setup.example" allow="local-network https://setup.example; loopback-network https://setup.example"></iframe>हेडर और iframe पॉलिसी परस्पर प्रतिच्छेद (intersect) करते हैं। कोई फ़्रेम पैरेंट अस्वीकृति को विस्तृत नहीं कर सकता। यदि फ़्रेम किसी अन्य ऑरिजिन पर नेविगेट करता है जो लोकल अनुरोध भी करता है, तो उस ऑरिजिन को स्पष्ट रूप से सूचीबद्ध करें या नेविगेशन के बाद एक्सेस से इनकार करें। नेस्टेड फ़्रेम्स को प्रत्येक सीमा पर पॉलिसी की आवश्यकता होती है।
चरण 4: अनुमति को मिक्स्ड कंटेंट और CORS से अलग करें
अनुमति किसी असुरक्षित अनुरोध को सार्वभौमिक रूप से मान्य नहीं बनाती है। कुछ ब्राउज़र कार्यान्वयन सहमति के बाद चयनित लोकल HTTP एंडपॉइंट्स की अनुमति देते हैं, जबकि अन्य मिक्स्ड-कंटेंट जाँच अभी भी लागू होती हैं। अनुरोध के टारगेट एड्रेस-स्पेस मेटाडेटा का उपयोग केवल तभी करें जब ब्राउज़र और एंडपॉइंट अनुबंध इसका समर्थन करते हों; इसका उपयोग किसी पब्लिक डेस्टिनेशन के बाईपास के रूप में न करें।
CORS जवाब देता है कि क्या टारगेट वेब ऑरिजिन को रिस्पॉन्स पढ़ने की अनुमति देता है। यह किसी पब्लिक पेज को प्रिंटर तक पहुँचने के लिए अधिकृत नहीं करता है, और यह डिवाइस ऑथेंटिकेशन की जगह नहीं ले सकता है। स्टेट-चेंजिंग कमांड के लिए, डिवाइस-विशिष्ट चैलेंज या पेयरिंग कोड का उपयोग करें और कमांड को आइडम्पोटेंट (idempotent) बनाएं।
चरण 5: फ़ॉलबैक और टेलीमेट्री डिज़ाइन करें
असमर्थित ब्राउज़रों को एक मैनुअल IP, एक नेटिव हेल्पर, या उपयोगकर्ता-निर्देशित पेयरिंग रूट दिखाना चाहिए। क्रेडेंशियल्स या रॉ लोकल रिस्पॉन्स को लॉग किए बिना डेस्टिनेशन क्लास, अनुमति स्थिति, पॉलिसी परिणाम, ब्राउज़र क्षमता, CORS परिणाम और डिवाइस-ऑथ परिणाम रिकॉर्ड करें। यदि कोई रिलीज़ किसी नए होस्ट क्लास को लोकल एक्सेस का अनुरोध करने का कारण बनती है या कोई विज्ञापन फ़्रेम इसका प्रयास करता है, तो प्रोडक्शन अलार्म बजना चाहिए।
चरण 6: नेगेटिव मैट्रिक्स का परीक्षण करें
localhost, एक प्राइवेट IP, सार्वजनिक रूप से रिज़ॉल्व होने वाले पब्लिक होस्टनाम, स्थानीय रूप से रिज़ॉल्व होने वाले पब्लिक होस्टनाम, एक HTTP पेज, गुम अनुमति, अस्वीकृत अनुमति, छूटे हुए iframe डेलिगेशन, एक नेस्टेड फ़्रेम, असूचीबद्ध ऑरिजिन पर नेविगेशन, ब्लॉक किए गए CORS रिस्पॉन्स, डिवाइस-ऑथ विफलता और ऐसे एड्रेस का परीक्षण करें जो DNS रिज़ॉल्यूशन के दौरान क्लास बदलता है। सत्यापित करें कि केवल इच्छित उपयोगकर्ता क्रिया ही प्रॉम्प्ट को ट्रिगर कर सकती है और कोई भी बैकग्राउंड रीट्राय किसी रेंज को स्कैन नहीं करता है।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं पब्लिक-से-लोकल अनुरोधों को एक ऐसी क्षमता मानूँगा जिसका अनुरोध किया जाना चाहिए और जिसका दायरा निर्धारित होना चाहिए। डैशबोर्ड HTTPS पर रहता है, प्रिंटर और हेल्पर डेस्टिनेशन्स को अलग-अलग वर्गीकृत करता है, local-network या loopback-network स्थिति की जाँच करता है, और एक बाउंडेड अनुरोध करने से पहले प्रॉम्प्ट की व्याख्या करता है। रिस्पॉन्स पॉलिसी वेंडर iframe के लिए दोनों सुविधाओं को अस्वीकार करती है। यदि एक विश्वसनीय सेटअप iframe की आवश्यकता है, तो इसकी allow सूची में केवल सेटअप ऑरिजिन और प्रत्येक ऑरिजिन शामिल होता है जिस पर वह नेविगेट कर सकता है।
मैं ब्राउज़र अनुमति, मिक्स्ड-कंटेंट जाँच, CORS और डिवाइस ऑथेंटिकेशन को अलग-अलग गेट्स के रूप में रखूँगा। अस्वीकृत या असमर्थित ब्राउज़र को बार-बार अनुरोधों के बजाय मैनुअल पेयरिंग मिलती है। टेस्ट्स में लोकल, लूपबैक, पब्लिक, DNS पुनर्वर्गीकरण, नेस्टेड फ़्रेम, अनुपलब्ध डेलिगेशन, अस्वीकृत अनुमति, CORS विफलता और डिवाइस-ऑथ विफलता शामिल हैं। यदि कोई विज्ञापन या मनमाना होस्ट किसी अनुरोध या प्रॉम्प्ट को ट्रिगर कर सकता है, तो रिलीज़ को रोक दिया जाता है।"
सामान्य गलतियाँ
- प्रत्येक प्राइवेट IP को लूपबैक मानना → लूपबैक और लोकल नेटवर्क में अलग-अलग अनुमति सिमेंटिक्स होते हैं → अनुमति चुनने से पहले डेस्टिनेशन को वर्गीकृत करें।
- प्रॉम्प्ट दिखाई देने तक अस्वीकृति के बाद पुनः प्रयास करना → यह आश्चर्य और स्कैन जैसा व्यवहार पैदा करता है → संदर्भ को एक बार दिखाएं और समाधान प्रदान करें।
- यह मान लेना कि CORS प्रिंटर को भरोसेमंद बनाता है → CORS रिस्पॉन्स शेयरिंग को नियंत्रित करता है, डिवाइस पहचान को नहीं → डिवाइस को पेयर करें और कमांड्स को ऑथेंटिकेट करें।
- वेंडर फ़्रेम को
local-network *प्रदान करना → रीडायरेक्ट और नेस्टेड दस्तावेज़ ट्रस्ट सेट का विस्तार कर सकते हैं → सटीक ऑरिजिन सूचीबद्ध करें या डेलिगेशन अस्वीकार करें। - केवल localhost टेस्ट पर निर्भर रहना → यह पब्लिक-से-लोकल सीमा का परीक्षण नहीं कर सकता है → प्रत्येक एड्रेस क्लास के विरुद्ध पब्लिक HTTPS ऑरिजिन से टेस्ट करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: localhost डेवलपमेंट में क्यों काम करता था लेकिन प्रोडक्शन में विफल हो गया?
डेवलपमेंट लूपबैक ऑरिजिन या नए प्रतिबंधों के बिना ब्राउज़र से चल सकता है। प्रोडक्शन एक पब्लिक ऑरिजिन है जो लूपबैक या लोकल स्पेस में जाता है, इसलिए सुरक्षित संदर्भ, अनुमति, पॉलिसी, मिक्स्ड-कंटेंट और CORS गेट्स सभी प्रासंगिक हो जाते हैं। पब्लिक HTTPS टेस्ट ऑरिजिन से पुनः पेश (reproduce) करें।
फॉलो-अप 2: क्या कोई iframe टॉप-लेवल की अनुमति को स्वचालित रूप से इनहेरिट कर सकता है?
केवल पॉलिसी और डेलिगेशन नियमों के भीतर। एक क्रॉस-ऑरिजिन फ़्रेम को एक स्पष्ट फीचर ग्रांट की आवश्यकता होती है, और नेस्टेड फ़्रेम्स को अपने स्वयं के डेलिगेशन की आवश्यकता होती है। उपयोगकर्ता का निर्णय एम्बेडिंग संदर्भ से जुड़ा होता है, लेकिन यह अनुपस्थित allow या असूचीबद्ध नेविगेशन ऑरिजिन को बाईपास नहीं करता है।
फॉलो-अप 3: क्या होगा यदि agent.example के लिए DNS पब्लिक से प्राइवेट में बदल जाता है?
रिज़ॉल्व किए गए एड्रेस को पुनर्वर्गीकृत करें और उचित अनुमति और सुरक्षित-संदर्भ पाथ की आवश्यकता रखें। किसी पब्लिक वर्गीकरण को हमेशा के लिए कैश न करें। वर्गीकरण ट्रांज़िशन को लॉग करें और यदि डेस्टिनेशन प्रोडक्ट के स्वीकृत टारगेट सेट में नहीं है, तो फ़ेल-क्लोज़्ड (fail closed) करें।
फॉलो-अप 4: प्रिंटर कमांड के लिए केवल अनुमति प्रॉम्प्ट ही पर्याप्त क्यों नहीं है?
प्रॉम्प्ट कहता है कि उपयोगकर्ता ने साइट से नेटवर्क एक्सेस की अनुमति दी है; यह डिवाइस को ऑथेंटिकेट नहीं करता है और न ही अनुरोधित ऑपरेशन को ऑथराइज करता है। डिवाइस को पेयर करें, कमांड्स को एक अकाउंट और नॉन्स (nonce) से बांधें, और रीट्राय को आइडम्पोटेंट बनाएं।