प्रॉम्प्ट और संदर्भ
टीम API दस्तावेज़, पेजिनेशन लिंक और /users{?status,limit} जैसे बैच-क्वेरी URLs के लिए URI Templates चाहती है। टेम्पलेट कॉन्फ़िगरेशन से आते हैं जबकि कुछ वेरिएबल मान उपयोगकर्ताओं से आते हैं। RFC 6570 एक्सप्रेशन स्तरों, आरक्षित-वर्ण और सूची विस्तार, और परिणाम को पार्स करने, विस्तारित करने और मान्य करने के लिए सुरक्षा सीमाओं की व्याख्या करें।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
- टेम्पलेट सिंटैक्स, वेरिएबल एन्कोडिंग, और अंतिम-URI पार्सिंग और सत्यापन को अलग करना।
- सरल, आरक्षित, पाथ, मैट्रिक्स-पैरामीटर, और क्वेरी विस्तार के बीच के अंतर को समझाना।
- सूचियों, एसोसिएटिव मैप्स, explode, उपसर्ग ट्रंकेशन, और अपरिभाषित वेरिएबल्स को संभालना।
- अविश्वसनीय टेम्पलेट्स से SSRF, पाथ ट्रैवर्सल, ओपन रीडायरेक्ट, और डेटा लीक जोखिमों को पहचानना।
पहले स्पष्ट करने योग्य प्रश्न
- क्या टेम्पलेट स्थिर कोड हैं, समीक्षित कॉन्फ़िगरेशन हैं, या टेनेंट/उपयोगकर्ता द्वारा प्रदान किए गए हैं?
- क्या परिणाम केवल प्रदर्शित किए जाते हैं, या सीधे सर्वर-साइड HTTP क्लाइंट द्वारा भेजे जाते हैं?
- क्या वेरिएबल्स स्ट्रिंग्स, सूचियाँ, एसोसिएटिव मैप्स या नेस्टेड JSON हैं?
- कौन सी स्कीम्स, होस्ट, पोर्ट और पाथ उपसर्ग अनुमत हैं; क्या परिणाम को वर्तमान API ओरिजिन पर ही रहना चाहिए?
- क्या कार्यान्वयन को सभी RFC 6570 स्तरों का समर्थन करना चाहिए, या केवल एक स्वीकृत ऑपरेटर सबसेट का?
30-सेकंड उत्तर ढांचा
मैं टेम्पलेट पार्सिंग, वेरिएबल एन्कोडिंग, और अंतिम-URI नीति को अलग रखूंगा। सबसे पहले समर्थित RFC 6570 ऑपरेटर्स और मान प्रकारों को परिभाषित करें, फिर प्रति ऑपरेटर प्रतिशत-एन्कोडिंग (percent-encoding), सूची और एसोसिएटिव-मैप विस्तार लागू करें; विनिर्देश के अनुसार अपरिभाषित वेरिएबल्स को छोड़ दिया जाना चाहिए। प्रत्येक विस्तारित मान को एक अविश्वसनीय URI के रूप में मानें, इसकी स्कीम, होस्ट, पोर्ट और सामान्यीकृत (normalized) पाथ को पार्स और सत्यापित करें, और कभी भी किसी टेम्पलेट को मनमाना सर्वर-साइड नेटवर्क लक्ष्य चुनने की अनुमति न दें। परीक्षणों में आरक्षित वर्ण, यूनिकोड, खाली मान, दोहराई गई कुंजियाँ, उपसर्ग और दुर्भावनापूर्ण पाथ शामिल होंगे।
चरण-दर-चरण विस्तृत उत्तर
चरण 1: URI Template सीमा को परिभाषित करें
URI Template वेरिएबल्स के साथ URI-संदर्भ व्यक्त करने के लिए एक सिंटैक्स है। यह कोई HTTP क्लाइंट, URL अनुमति सूची (allowlist), या व्यावसायिक राउटर नहीं है। कार्यान्वयन को मानों से परिणाम उत्पन्न करने से पहले लिटरल्स और एक्सप्रेशन्स को पार्स करना चाहिए; इसे टेम्पलेट को किसी अनुरोध में संयोजित (concatenate) नहीं करना चाहिए या विस्तारित मान को पहले से सुरक्षित URL नहीं मानना चाहिए।
चरण 2: स्तर के अनुसार ऑपरेटर्स लागू करें
RFC 6570 सरल वेरिएबल विस्तार से शुरू होता है और आरक्षित-वर्ण, फ्रैगमेंट, लेबल, पाथ-सेगमेंट, मैट्रिक्स-पैरामीटर, क्वेरी और क्वेरी-कंटिन्यूएशन रूपों को जोड़ता है। सामान्य ऑपरेटर्स में +, #, ., /, ;, ?, और & शामिल हैं। ऑपरेटर्स विभाजक (separators), खाली-मान व्यवहार और कौन से आरक्षित वर्ण रह सकते हैं, इसे परिभाषित करते हैं; एक सामान्य स्ट्रिंग-प्रतिस्थापन नियम अपर्याप्त है।
चरण 3: एन्कोडिंग और समग्र मानों को संभालें
एक सरल स्ट्रिंग में आरक्षित वर्णों को एक्सप्रेशन के अनुसार प्रतिशत-एन्कोड किया जाता है। एक सूची को अल्पविराम से जोड़ा जा सकता है या दोहराए गए मापदंडों में विस्तारित (exploded) किया जा सकता है; एसोसिएटिव मैप्स के अपने की/वैल्यू विभाजक होते हैं। एक उपसर्ग संशोधक (prefix modifier) एक स्ट्रिंग उपसर्ग लेता है और इसे यूनिकोड-वर्ण गणना, बाइट गणना, या सुरक्षित ट्रंकेशन के रूप में गलत नहीं समझा जाना चाहिए। UTF-8, खाली स्ट्रिंग्स और अपरिभाषित वेरिएबल्स के लिए व्यवहार निर्दिष्ट करें।
चरण 4: टेम्पलेट और वेरिएबल स्रोतों को अलग करें
स्थिर, कोड-समीक्षित टेम्पलेट्स अधिक ऑपरेटर्स का समर्थन कर सकते हैं; टेनेंट कॉन्फ़िगरेशन को एक्सप्रेशन्स, वेरिएबल नामों और आउटपुट घटकों को प्रतिबंधित करना चाहिए। मान किसी अनुरोध से आ सकते हैं, लेकिन एक टेम्पलेट को फ़ंक्शन कॉल नहीं करना चाहिए, पर्यावरण वेरिएबल्स नहीं पढ़ना चाहिए, या एक मनमाना स्कीम नहीं बनाना चाहिए। टेम्पलेट AST को मान मानचित्र से अलग रखें ताकि एक वेरिएबल नाम नया एक्सप्रेशन सिंटैक्स इंजेक्ट न कर सके।
चरण 5: अंतिम URI को सत्यापित करें
विस्तार के बाद, स्कीम, प्राधिकरण (authority), पाथ, क्वेरी और फ्रैगमेंट के लिए एक मानक URI पार्सर का उपयोग करें। सर्वर-साइड अनुरोधों के लिए, स्कीम, होस्ट और पोर्ट को एक अनुमति सूची से मेल खाना चाहिए; DNS रिज़ॉल्यूशन को लूपबैक, लिंक-लोकल और निजी पतों को भी ब्लॉक करना चाहिए, और रीडायरेक्ट की फिर से जाँच की जानी चाहिए। अपनी अनुमत रूट की जाँच करने से पहले पाथ को सामान्यीकृत (normalize) करें ताकि एन्कोड किया गया .. नियम को बायपास न कर सके।
चरण 6: API लिंक को बनाए रखने योग्य बनाएं
पेजिनेशन टेम्पलेट्स को यह निर्दिष्ट करना चाहिए कि कौन से वेरिएबल्स सर्वर-जनरेटेड हैं, जबकि फ़िल्टर निश्चित वेरिएबल नामों और प्रकारों का उपयोग करते हैं। सार्वजनिक टेम्पलेट्स या परिणामों में हस्ताक्षर, एक्सेस टोकन, या आंतरिक होस्टनाम न डालें। टेम्पलेट संस्करणों, वेरिएबल स्कीमा और विस्तार त्रुटियों को रिकॉर्ड करें। यदि स्थिर क्रम की आवश्यकता है, तो पैरामीटर-स्ट्रिंग क्रम पर भरोसा करने के बजाय व्यावसायिक परत को इसे प्रदान करना चाहिए।
चरण 7: परीक्षण और निगरानी का निर्माण करें
विनिर्देश उदाहरणों के विरुद्ध एकल मानों, सूचियों, मैप्स, खाली मानों और अपरिभाषित मानों के साथ प्रत्येक ऑपरेटर का परीक्षण करें। आरक्षित वर्ण, यूनिकोड, दोहराई गई क्वेरी कुंजियाँ, लंबे उपसर्ग, दोहरा एन्कोडिंग, %2e%2e, वैकल्पिक स्कीम्स, रीडायरेक्ट और DNS-रिज़ॉल्यूशन केस जोड़ें। विस्तार विफलताओं, अस्वीकृति कारणों, गंतव्य-उत्पत्ति वितरण, और असामान्य लंबाइयों की निगरानी करें, और टेम्पलेट कॉन्फ़िगरेशन बदलने पर समीक्षा ट्रिगर करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं सबसे पहले समर्थित RFC 6570 ऑपरेटर्स को प्रतिबंधित करूंगा और टेम्पलेट AST, वेरिएबल स्कीमा, प्रतिशत-एन्कोडिंग, और अंतिम URI सत्यापन को अलग करूंगा। सूचियाँ, मैप्स, explode, और उपसर्ग अपने व्यक्तिगत नियमों का पालन करते हैं, और अपरिभाषित वेरिएबल्स को छोड़ दिया जाता है; मानों को एक्सप्रेशन्स के रूप में पुन: पार्स नहीं किया जा सकता है। प्रत्येक परिणाम एक अविश्वसनीय URI बना रहता है: इसे पार्स करें, केवल API की स्कीम, होस्ट, पोर्ट और सामान्यीकृत पाथ की अनुमति दें, सर्वर-साइड अनुरोधों के लिए निजी पतों को ब्लॉक करें, और प्रत्येक रीडायरेक्ट की फिर से जाँच करें। परीक्षण RFC उदाहरणों, यूनिकोड, खाली मानों, दोहराई गई कुंजियों, दोहरे एन्कोडिंग, ट्रैवर्सल और SSRF को कवर करते हैं, जिसमें टेम्पलेट संस्करण और अस्वीकृति कारणों को रिकॉर्ड किया जाता है।
सामान्य गलतियाँ
- ऑपरेटर सिमेंटिक्स को स्ट्रिंग संयोजन (concatenation) से बदलना और विभाजकों या प्रतिशत-एन्कोडिंग को तोड़ना।
+आरक्षित विस्तार को "कोई एन्कोडिंग नहीं" के रूप में मानना और घटक सीमाओं की अनदेखी करना।- सूचियों, मैप्स, और explode को एक अल्पविराम-जोड़ने वाले प्रारूप के रूप में मानना।
- विस्तारित स्कीम, होस्ट, पोर्ट और सामान्यीकृत पाथ के बजाय केवल टेम्पलेट टेक्स्ट को मान्य करना।
- URL एन्कोडिंग को SSRF सुरक्षा के रूप में मानना और बिना पुन: सत्यापन के रीडायरेक्ट का पालन करना।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: किसी अपरिभाषित वेरिएबल के साथ क्या होना चाहिए?
एक्सप्रेशन के अनुसार अपरिभाषित वेरिएबल और आवश्यक विभाजक को छोड़ दें। null स्ट्रिंग को रेंडर न करें। यदि व्यावसायिक स्कीमा को वेरिएबल की आवश्यकता है, तो विस्तार से पहले इसे अस्वीकार करें।
अनुवर्ती 2: केवल एक URL-एन्कोड फ़ंक्शन को कॉल क्यों न करें?
एन्कोडिंग एक्सप्रेशन और URI घटक पर निर्भर करती है। क्वेरी पैरामीटर, पाथ सेगमेंट और आरक्षित विस्तार के अलग-अलग विभाजक और नियम होते हैं। एक फ़ंक्शन समग्र मानों, खाली मानों, उपसर्गों और ऑपरेटर्स का निर्णय नहीं ले सकता है।
अनुवर्ती 3: आप टेनेंट टेम्पलेट्स के लिए जोखिम को कैसे कम करते हैं?
एक समीक्षित ऑपरेटर सबसेट, निश्चित वेरिएबल स्कीमा और निश्चित आउटपुट घटकों का उपयोग करें। मनमानी स्कीम्स या प्राधिकरणों को अस्वीकार करें, फिर भी विस्तार के बाद ओरिजिन अनुमति सूची, पाथ सामान्यीकरण, DNS/IP जाँच और रीडायरेक्ट पुन: सत्यापन लागू करें।
अनुवर्ती 4: क्या एक उपसर्ग संशोधक किसी गुप्त (secret) डेटा को ट्रंकेट कर सकता है?
यह URI Template स्ट्रिंग-उपसर्ग सिमेंटिक्स है, गोपनीयता मास्किंग या यूनिकोड-सुरक्षित ट्रंकेशन नहीं। व्यावसायिक परत में संवेदनशील डेटा को मास्क करें, जहाँ लंबाई और वर्ण सीमाएँ स्पष्ट नीति हों।
अनुवर्ती 5: आप RFC 6570 संगतता कैसे साबित करते हैं?
RFC 6570 विनिर्देश उदाहरणों और ऑपरेटर-स्तरीय परीक्षणों को चलाएं, प्रत्येक वेरिएबल प्रकार के लिए अपेक्षित विस्तार की तुलना करें, फिर प्रोजेक्ट-विशिष्ट अस्वीकृति केस जोड़ें और असमर्थित स्तरों और अंतरों का दस्तावेजीकरण करें।