डेवलपर टूल · URL एनकोडर और डिकोडर
किसी क्वेरी पैरामीटर के अंदर रीडायरेक्ट URL को बिना तोड़े एन्कोड करना
· यह काम किस प्रकार करता है
URL एन्कोडिंग क्वेरी-पैरामीटर सुरक्षा शपथ
एक URL को दूसरे के अंदर रखना सबसे आम जगह है जहां प्रतिशत-एन्कोडिंग गलत हो जाती है। यह पोस्ट दिखाती है कि आंतरिक URL के ?, & और = को एन्कोड क्यों किया जाना चाहिए, इसे कैसे करना है, और परिणाम की जांच कैसे करें।
रिटर्न-टू लिंक जिसने अपने आधे मापदंडों को गिरा दिया - एक आंतरिक URL और बाहरी क्वेरी स्ट्रिंग द्वारा निगल लिया गया
रिटर्न-टू लिंक जिसने अपने आधे मापदंडों को गिरा दिया है वह एक डिबगिंग पैटर्न है जिसका हर डेवलपर सामना करता है। एक उपयोगकर्ता लॉग इन करता है, एप्लिकेशन ?next=https://example.com/page?id=1&user=alice, पर रीडायरेक्ट करने का प्रयास करता है और वे example.com/page?id=1 पर पहुंच जाते हैं। आंतरिक URL में एम्परसेंड को बाहरी क्वेरी पैरामीटर के बीच विभाजक के रूप में पार्स किया गया था। अलग-अलग सीमांकक वाले दो URL का मतलब है कि आंतरिक को एन्कोड किया जाना चाहिए।
जब एक URL को क्वेरी पैरामीटर के रूप में दूसरे के अंदर नेस्ट किया जाता है, तो वह आंतरिक पता बाहरी परत के लिए अपारदर्शी डेटा बन जाता है। प्रश्न चिह्न, एम्परसेंड और बराबर चिह्न संरचनात्मक सीमांकक के रूप में पढ़ने योग्य नहीं होने चाहिए। प्रतिशत-एन्कोडिंग उन्हें बदल देती है: ? %3F हो जाता है, और %26 हो जाता है, = %3D बन जाता है। बाहरी पार्सर फिर एन्कोडेड स्ट्रिंग को एक पैरामीटर मान के रूप में मानता है।
दो URL, सीमांकक के दो सेट - आंतरिक URL बाहरी के लिए सिर्फ एक मान क्यों है
पूरे अंदरूनी URL पर encodeURIComponent पूरी सुरक्षा देता है: encodeURIComponent("https://example.com/a?b=1&c=2") से "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2" मिलता है। हर संरचनात्मक कैरेक्टर %XX रूप लेता है, इसलिए बाहरी पार्सर अंदर के डिलिमिटर गलत नहीं समझता। encodeURI जैसा तरीका स्लैश और प्रश्न चिह्न छोड़ देता है, जिससे नतीजा क्वेरी वैल्यू बनने पर अस्पष्टता लौट आती है।
सर्वर बिल्कुल एक बार डिकोड करता है। अगला पैरामीटर निकालने के बाद, एक एकल decodeURIComponent कॉल आंतरिक URL को उसके मूल रूप में पुनर्स्थापित करता है। परिणाम को एक नई क्वेरी स्ट्रिंग के रूप में पार्स करने पर सही पैरामीटर संरचना दिखाई देती है। जब एक ही मान कई परतों से होकर गुजरता है तो डबल-डिकोडिंग एक जोखिम है; %26 एक डिकोड के बाद & बन जाता है और दूसरे के बाद & रहता है।
संपूर्ण आंतरिक URL पर encodeURIComponent - क्या एन्कोड किया जाता है, जिसमें :, / और ?
मूल नियम सरल है: कोई भी वर्ण जिसका URL वाक्यविन्यास में अर्थ है, जिसमें शामिल है: / ? = & #, क्वेरी पैरामीटर मान में प्रकट होने पर प्रतिशत-एन्कोडेड होना चाहिए। यह सुनिश्चित करता है कि बाहरी पार्सर केवल आपके इच्छित पैरामीटर संरचना को देखता है, न कि आपके द्वारा पारित किए जा रहे मान के अंदर छिपा कोई आकस्मिक सीमांकक। इस एन्कोडिंग को पूरी तरह और विश्वसनीय रूप से संभालने के लिए encodeURIComponent का उपयोग करें।
इस एन्कोडिंग का परीक्षण URL एनकोडर और डिकोडर में करें: आंतरिक URL को पेस्ट करें, इसे वैल्यू मोड में एन्कोड करें, %XX आउटपुट का निरीक्षण करें। राउंड ट्रिप मिलान को सटीक रूप से सत्यापित करने के लिए डिकोडर मोड का उपयोग करें। यह टूल शुरू से अंत तक एन्कोडिंग प्रदर्शित करता है ताकि आप आत्मविश्वास के साथ परिणामों को सीधे अपने एप्लिकेशन कोड में कॉपी कर सकें।
कार्यान्वित उदाहरण: ?next=https://example.com/a?b=1&c=2 को सही ढंग से बनाना - एन्कोडेड स्ट्रिंग और सर्वर साइड पर डिकोड
एक महत्वपूर्ण सुरक्षा सीमा एन्कोडिंग के साथ-साथ बैठती है। सर्वर को यह सत्यापित करना होगा कि डिकोड किया गया गंतव्य वास्तव में रीडायरेक्ट करने के लिए सुरक्षित है। प्रतिशत-एन्कोडिंग URL संरचना को स्पष्ट बनाती है; यह मनमाने URL को सुरक्षित नहीं बनाता है। ओपन-रीडायरेक्ट कमजोरियाँ तब होती हैं जब एप्लिकेशन उपयोगकर्ता द्वारा प्रदत्त URL का आँख बंद करके अनुसरण करते हैं। सत्यापन के लिए एक स्पष्ट अनुमति सूची, डोमेन सत्यापन या उपयोगकर्ता पुष्टि की आवश्यकता होती है।
एन्कोडिंग पार्सिंग समस्या को ठीक करता है; सत्यापन सुरक्षा समस्या को ठीक करता है। ये विभिन्न स्तरों पर अलग-अलग चिंताएँ हैं। URL एन्कोडर और डिकोडर एन्कोडिंग को सही ढंग से प्रदर्शित करता है। एक सर्वर को सत्यापन जोड़ना होगा: किसी सूची के विरुद्ध जांच करना, डोमेन को सत्यापित करना, या पुष्टि के लिए पूछना। सत्यापन के बिना, किसी भी डोमेन पर उचित रूप से एन्कोड किया गया रीडायरेक्ट शोषण योग्य रहता है।
ओपन-रीडायरेक्ट जोखिम - क्यों सर्वर को डिकोड किए गए गंतव्य को मान्य करना चाहिए, न कि केवल इसे डिकोड करना चाहिए
सामान्य गलतियाँ यहाँ जमा होती हैं। डेवलपर्स कभी-कभी केवल क्वेरी भाग को एन्कोड करते हैं, स्लैश को अछूता छोड़ देते हैं, जो संरचना को तोड़ देता है। अन्य लोग ?next= सहित पूरे निर्मित पैरामीटर को एनकोड करते हैं, जिससे डबल-एन्कोडिंग बनती है। कुछ लोग डिकोडिंग के बिना पार्सिंग करके, एन्कोडेड संरचना को गलत तरीके से पढ़कर वैधता की जांच करते हैं। EncodeURIComponent के साथ निर्माण हर मामले में स्थिरता और शुद्धता सुनिश्चित करता है।
एक अन्य सामान्य गलती ब्राउज़र पर भरोसा करना है कि वह किसी विकृत पैरामीटर को स्वचालित रूप से ठीक कर देगा। URL डेटा हैं और इन्हें सटीक रूप से डेटा के रूप में माना जाना चाहिए। encodeURIComponent इस कार्य के लिए मानक टूल है। URL एनकोडर और डिकोडर इस प्रक्रिया को स्थानीय रखता है ताकि आप उत्पादन के लिए शिपिंग से पहले सटीक बाइट्स को सत्यापित कर सकें।
सामान्य गलतियाँ - केवल क्वेरी भाग को एन्कोड करना, या इसे ठीक करने के लिए ब्राउज़र पर भरोसा करना
OAuth रीडायरेक्ट_यूरी पैरामीटर बिल्कुल इसी पैटर्न का पालन करते हैं। प्राधिकरण सर्वर किसी ज्ञात पते पर क्लाइंट को नियंत्रण भेजता है, जो अक्सर कई मापदंडों के साथ पूर्ण URL होता है। इसे एकल मान के रूप में एन्कोड करने से यह सुनिश्चित होता है कि पैरामीटर परिवहन से बचे रहें, और क्लाइंट उपयोग से पहले एक बार डिकोड करता है। OAuth प्रवाह में गलत एन्कोडिंग के कारण टोकन और कॉलबैक पैरामीटर ट्रांसमिशन के बीच में गायब हो जाते हैं।
OAuth में राज्य पैरामीटर CSRF सुरक्षा के लिए क्रिप्टोग्राफ़िक हस्ताक्षरों के साथ संयुक्त एन्कोडिंग का उपयोग करते हैं। फ़्रैगमेंट पहचानकर्ता क्लाइंट साइड पर रहते हैं और कभी भी सर्वर पर नहीं जाते हैं। एन्कोडिंग की परवाह किए बिना बियरर टोकन को कभी भी रीडायरेक्ट URL में नहीं रखा जाना चाहिए, क्योंकि URL लॉग, ब्राउज़र इतिहास और रेफरर हेडर में दिखाई देते हैं।
इसमें क्या शामिल नहीं है - OAuth राज्य पैरामीटर और CSRF सुरक्षा डिज़ाइन
परीक्षण रणनीति: वास्तविक मापदंडों के साथ अपने आंतरिक URL का निर्माण करें, इसे बाहरी मान के रूप में एनकोड करें, प्राप्त कोड में इसे डीकोड करें। सत्यापित करें कि डिकोड किया गया परिणाम बाइट-दर-बाइट मूल के समान है। उत्पादन परिनियोजन से पहले URL एनकोडर और डिकोडर का उपयोग करें। सही आगमन की पुष्टि करने के लिए नेटवर्क ट्रैफ़िक और लॉग की जांच करें और एन्कोडेड डेटा में कोई कटौती या गड़बड़ी न हो।
%2E के बजाय %2e जैसा टाइपो सही ढंग से डिकोड हो सकता है, लेकिन निरंतरता की अपेक्षा रखने वाले सेकेंडरी सिस्टम में राउंड-ट्रिप चेक विफल हो सकता है। विभिन्न प्लेटफार्मों पर पुस्तकालयों के बीच एन्कोडिंग बेमेल दुर्लभ लेकिन संभव है; संपूर्ण राउंड ट्रिप का परीक्षण करने से उन्हें उत्पादन संबंधी समस्याएं और ग्राहक शिकायतें पैदा होने से पहले ही पकड़ लिया जाता है।
टेकअवे: आंतरिक URL को डेटा के रूप में मानें - कैसे URL एनकोडर और डिकोडर का एकल-मूल्य मोड इसे पूरी तरह से एनकोड करता है और इसका डिकोडर राउंड ट्रिप की पुष्टि करता है
एन्कोडिंग सीमा स्पष्ट है: encodeURIComponent आपके इनपुट को अपारदर्शी डेटा के रूप में मानता है और अनारक्षित विराम चिह्न को छोड़कर प्रत्येक वर्ण से बच जाता है, जिससे इसे किसी भी URL परत में घोंसला बनाना सुरक्षित हो जाता है। सत्यापन सीमा अलग है: डिकोडिंग के बाद, सत्यापित करें कि गंतव्य वह जगह है जहां उपयोगकर्ता जाना चाहता है। एन्कोडिंग को शुरू से अंत तक देखने के लिए URL एनकोडर और डिकोडर का उपयोग करें।
आंतरिक URL को प्रारंभ से ही डेटा मानें। इसे एकल क्वेरी मान के रूप में एनकोड करें, प्राप्त होने पर ठीक एक बार डीकोड करें, फिर रीडायरेक्ट करने से पहले सत्यापन लागू करें। URL एनकोडर और डिकोडर एकल क्वेरी मान के रूप में किसी भी पूर्ण URL का प्रतिशत-एन्कोडिंग दिखाता है और स्थानीय रूप से राउंड ट्रिप को सत्यापित करता है। एन्कोडिंग और सत्यापन दोनों आवश्यक हैं; यह टूल एन्कोडिंग को सही ढंग से संभालता है।