बैकएंड इंटरव्यू: आप URL-फेचिंग सर्विस में SSRF को कैसे रोकते हैं?

प्रॉम्प्ट और प्रासंगिक संदर्भ

URL प्रिव्यू API के लिए सिक्योर फेच पाथ डिज़ाइन करें। एक ऑथेंटिकेटेड यूज़र कोई भी आर्बिट्रेरी पब्लिक HTTP या HTTPS URL सबमिट करता है। एक बैकग्राउंड वर्कर डॉक्यूमेंट को फेच करता है और केवल सैनिटाइज़्ड पेज टाइटल लौटाता है। प्रोडक्ट एक फिक्स्ड डोमेन अनुमति सूची (allowlist) नहीं रख सकता क्योंकि पब्लिक वेबसाइट्स ही इसका इच्छित इनपुट हैं।

इस इंटरव्यू के लिए, केवल डिफ़ॉल्ट पोर्ट 80 और 443 की अनुमति दें, अधिकतम तीन रीडायरेक्ट्स फॉलो करें, कुल तीन-सेकंड की डेडलाइन लागू करें, और डीकंप्रेशन के बाद अधिकतम 2 MiB पढ़ें। ये संख्याएं यूनिवर्सल सिक्योरिटी सेटिंग्स के बजाय इंटरव्यू की धारणाएं (assumptions) हैं। सर्विस को IPv4 या IPv6 पर लूपबैक, प्राइवेट, शेयर्ड, लिंक-लोकल, मल्टीकास्ट, रिज़र्व्ड, डॉक्यूमेंटेशन या क्लाउड-मेटाडेटा डेस्टिनेशन्स तक नहीं पहुँचना चाहिए। इसे वैकल्पिक IP नोटेशन, मिक्स्ड DNS आंसर्स, DNS रीबाइंडिंग, इंटरनल एड्रेस पर रीडायरेक्ट करने वाले पब्लिक URL, ओवरसाइज़्ड रिस्पॉन्स और स्लो सर्वर्स का भी सफलतापूर्वक सामना करना होगा।

MITRE CWE-918 को इस रूप में परिभाषित करता है कि एक सर्वर URL प्राप्त करता है और यह पर्याप्त रूप से सुनिश्चित किए बिना उसे रिट्रीव करता है कि रिक्वेस्ट अपेक्षित डेस्टिनेशन तक पहुँचती है या नहीं। यह फ़्रेमिंग उपयोगी है: मुख्य समस्या आउटबाउंड ऑथराइजेशन की है। इनपुट वैलिडेशन, DNS बिहेवियर, नेटवर्क रूट और वास्तविक सॉकेट डेस्टिनेशन को एक ही पॉलिसी लागू करनी चाहिए। 2026 की एक सार्वजनिक वेब-सुरक्षा इंटरव्यू चर्चा में SSRF को XSS, SQL इंजेक्शन और IDOR के साथ ऐसे विषयों के रूप में सूचीबद्ध किया गया है जिन्हें समझाने के लिए उम्मीदवारों को तैयार रहना चाहिए। यह वर्तमान इंटरव्यू प्रासंगिकता का समर्थन करता है लेकिन किसी निश्चित कंपनी के प्रश्न या फ़्रीक्वेंसी का दावा स्थापित नहीं करता है। OWASP Top 10:2025 CWE-918 को ब्रोकन एक्सेस कंट्रोल में मैप करता है, जो ऑथराइजेशन मॉडल को सुदृढ़ करता है।

मौजूदा प्रश्न बैंक क्रॉलर और URL शॉर्टनर में SSRF को एक बाउंड्री के रूप में उल्लेख करता है। यह प्रश्न फेच पाथ को ही अलग करता है: पार्सिंग, रिज़ॉल्यूशन, डेस्टिनेशन क्लासिफिकेशन, कनेक्शन बाइंडिंग, रीडायरेक्ट्स, इग्रेस कंट्रोल्स, और यह प्रमाण कि पॉलिसी टाइम-ऑफ-चेक/टाइम-ऑफ-यूज़ रेस में भी सुरक्षित रहती है।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार डेस्टिनेशन को एक ऑथराइजेशन निर्णय के रूप में मॉडल करता है। localhost और 127.0.0.1 स्ट्रिंग्स के लिए एक चेक अधूरा है। डेस्टिनेशन एक IPv6 लिटरल, एक IPv4-मैप्ड IPv6 एड्रेस, एक वैकल्पिक संख्यात्मक प्रतिनिधित्व, सुरक्षित और असुरक्षित दोनों आंसर्स वाला एक होस्टनेम, एक रीडायरेक्ट टारगेट, या ऐसा नाम हो सकता है जिसका DNS आंसर वैलिडेशन और कनेक्शन के बीच बदल जाता है।

दूसरा संकेत पार्सर अनुशासन है। Regex और सबस्ट्रिंग चेक्स URL सिमेंटिक्स को परिभाषित नहीं करते हैं। एक मजबूत उत्तर एक मानक-आधारित पार्सर का उपयोग करता है, पार्स विफलताओं और एम्बेडेड क्रेडेंशियल्स को अस्वीकार करता है, केवल स्पष्ट HTTP स्कीम्स और अपेक्षित पोर्ट्स की अनुमति देता है, और फिर पार्सर के विहित (canonical) फ़ील्ड्स से सभी पॉलिसी निर्णय लेता है। सॉकेट को जाँचे गए IP एड्रेस पर पिन किए जाने पर भी TLS वेरिफिकेशन अभी भी मूल नॉर्मलाइज़्ड होस्टनेम का उपयोग करता है।

तीसरा संकेत DNS रीबाइंडिंग गैप को बंद करना है। IP को रिज़ॉल्व और स्वीकृत करना अप्रभावी होता है जब HTTP लाइब्रेरी सॉकेट खोलने से पहले दूसरा DNS लुकअप करती है। फ़ेचर को एक विशिष्ट स्वीकृत एड्रेस से कनेक्ट होना चाहिए, या पॉलिसी-अवेयर इग्रेस प्रॉक्सी के माध्यम से रिक्वेस्ट भेजनी चाहिए जो ऐसा करती है। प्रत्येक रीडायरेक्ट और पुनः प्रयास (retry) एक नया ऑथराइजेशन इवेंट होता है।

चौथा संकेत डिफेंस इन डेप्थ है। एप्लिकेशन बग को ऐसी नेटवर्क बाउंड्री से टकराना चाहिए जो इंटरनल सबनेट्स या मेटाडेटा एंडपॉइंट्स पर रूट नहीं कर सकती। वर्कर के पास न्यूनतम पहचान विशेषाधिकार (identity privileges) होने चाहिए, कोई एम्बिएंट यूज़र कुकीज़ या ऑथराइजेशन हेडर नहीं होने चाहिए, एक बाउंडेड पार्सर होना चाहिए, और पेज स्क्रिप्ट्स को निष्पादित करने या सब-रिसोर्स को फेच करने की कोई क्षमता नहीं होनी चाहिए।

अंतिम संकेत गलत साबित करने योग्य (falsifiable) वैलिडेशन है। उम्मीदवार को ऐसे टेस्ट्स प्रस्तावित करने चाहिए जो वैकल्पिक एड्रेस फ़ॉर्म्स, मिक्स्ड A और AAAA रिकॉर्ड्स, री-रिज़ॉल्यूशन रेस, रीडायरेक्ट्स, डीकंप्रेशन लिमिट्स और इग्रेस फ़ायरवॉल नियमों का परीक्षण करते हैं। "अनुमति सूची का उपयोग करें" कहना इस प्रॉम्प्ट को हल नहीं करता है क्योंकि आर्बिट्रेरी पब्लिक डोमेन एक प्रोडक्ट आवश्यकता हैं; यह केवल एक अलग, पार्टनर-ओनली स्कोप के लिए उपयुक्त है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या डेस्टिनेशन आर्बिट्रेरी पब्लिक साइट्स हैं या ज्ञात पार्टनर्स? ज्ञात पार्टनर्स एक सटीक स्कीम-होस्ट-पोर्ट अनुमति सूची की अनुमति देते हैं। आर्बिट्रेरी प्रिव्यूज़ के लिए एक रूढ़िवादी पब्लिक-एड्रेस पॉलिसी और नेटवर्क-लागू इग्रेस बाउंड्री की आवश्यकता होती है।
• कौन से प्रोटोकॉल, पोर्ट, मेथड्स और हेडर्स आवश्यक हैं? यह प्रॉम्प्ट केवल पोर्ट 80 पर HTTP या पोर्ट 443 पर HTTPS के माध्यम से GET की अनुमति देता है। यह कॉलर-चयनित मेथड्स, रिक्वेस्ट बॉडीज़, प्रॉक्सीज़, कुकीज़, ऑथराइजेशन हेडर्स या आर्बिट्रेरी हेडर्स को स्वीकार नहीं करता है।
• क्या रीडायरेक्ट्स आवश्यक हैं? वे हैं, अधिकतम तीन हॉप्स तक। सर्विस ऑटोमैटिक रीडायरेक्ट्स को अक्षम करती है और इसे फॉलो करने से पहले प्रत्येक Location टारगेट को स्वतंत्र रूप से ऑथराइज़ करती है।
• किस आउटपुट की आवश्यकता है? केवल एक सैनिटाइज़्ड टाइटल। वर्कर रॉ HTML नहीं लौटाता है, जावास्क्रिप्ट निष्पादित नहीं करता है, XML एक्सटर्नल एंटिटीज़ को प्रोसेस नहीं करता है, इमेजेस रेंडर नहीं करता है, या स्टाइलशीट्स, फ़ॉन्ट्स या स्क्रिप्ट्स को फेच नहीं करता है।
• वर्कर से कौन सा एड्रेस स्पेस पहुँच योग्य है? उत्तर में IPv4, IPv6, कंटेनर और सर्विस-नेटवर्क रूट्स, कॉर्पोरेट नेटवर्क और प्रोवाइडर मेटाडेटा एंडपॉइंट्स शामिल होने चाहिए। इग्रेस पॉलिसी का परीक्षण करने से पहले एक इन्वेंट्री की आवश्यकता होती है।
• कैश और पुनः प्रयास (retries) को कैसा व्यवहार करना चाहिए? एक कैश्ड प्रिव्यू बार-बार होने वाली फेचिंग को कम कर सकता है, लेकिन कैश मिस अभी भी सुरक्षित पाथ से होकर गुजरते हैं। यह डिज़ाइन अपने आप पुनः प्रयास नहीं करता है। एक स्पष्ट पुनः प्रयास शुरुआत से DNS रिज़ॉल्यूशन, ऑथराइजेशन और कनेक्शन पिनिंग को दोहराता है।
• कौन सा उपलब्धता ट्रेडऑफ़ स्वीकार्य है? जब कोई भी लौटाया गया एड्रेस असुरक्षित हो, तो होस्टनेम को अस्वीकार करना गलत कॉन्फ़िगर की गई पब्लिक साइट को ब्लॉक कर सकता है। प्रॉम्प्ट आंशिक पहुंच की तुलना में सुरक्षा को चुनता है; अस्वीकृति ऑब्ज़र्वेबल होती है और चुपचाप किसी अन्य उत्तर का चयन नहीं करती है।

30-सेकंड उत्तर फ़्रेमवर्क

"मैं एक मानक-आधारित URL पार्सर के साथ पार्स करूँगा, केवल पोर्ट 80 पर HTTP या पोर्ट 443 पर HTTPS की अनुमति दूँगा, और क्रेडेंशियल्स को अस्वीकार करूँगा। मैं एक विश्वसनीय रिज़ॉल्वर के माध्यम से प्रत्येक A और AAAA उत्तर को रिज़ॉल्व करूँगा, IPv4-मैप्ड IPv6 को नॉर्मलाइज़ करूँगा, और यदि कोई भी एड्रेस मेंटेन की गई पब्लिक-एड्रेस पॉलिसी से बाहर है तो डेस्टिनेशन को अस्वीकार करूँगा। वर्कर सीधे एक स्वीकृत IP से जुड़ता है लेकिन Host, TLS SNI और सर्टिफ़िकेट वेरिफिकेशन के लिए होस्टनेम रखता है, जिससे DNS-रीबाइंडिंग गैप बंद हो जाता है। ऑटोमैटिक रीडायरेक्ट्स और पुनः प्रयास बंद रहते हैं; प्रत्येक रीडायरेक्ट पूरी जांच दोहराता है। एक आइसोलेटेड इग्रेस फ़ायरवॉल इंटरनल और मेटाडेटा रूट्स को ब्लॉक करता है। फिर मैं तीन-सेकंड, 2 MiB, और तीन-हॉप सीमाओं को लागू करता हूँ, कोई सब-रिसोर्स लोड नहीं करता हूँ, और रीबाइंडिंग तथा रीडायरेक्ट-टू-मेटाडेटा का शुरू से अंत तक परीक्षण करता हूँ।"

स्टेप-बाय-स्टेप डीप डाइव

स्टेप 1: आवश्यकता को एक डेस्टिनेशन पॉलिसी में बदलें

API, वर्कर और HTTP क्लाइंट में स्ट्रिंग चेक्स को वितरित करने के बजाय पॉलिसी को स्पष्ट रूप से दर्शाएं:

DestinationPolicy
  schemes: http, https
  origin_pairs: http:80, https:443
  userinfo: forbidden
  address_requirement: globally reachable public unicast
  redirects: at most 3, authorize every hop
  method: GET
  caller_headers: none
  total_deadline: 3 seconds
  decompressed_body_limit: 2 MiB

API कॉलर को ऑथेंटिकेट करता है, अकाउंट और टेनेंट कोटा लागू करता है, सबमिट की गई स्ट्रिंग को अनट्रस्टेड डेटा के रूप में स्टोर करता है, और एक जॉब कतारबद्ध (queue) करता है। यह "सुरक्षा जांच" करके बाद के वर्कर को एक ट्रस्टेड फ़्लैग पास नहीं करता है; जॉब चलने से पहले DNS और रूट्स बदल सकते हैं। वर्कर वह कॉम्पोनेन्ट है जो कनेक्शन खोलता है, इसलिए यह कनेक्ट करने से ठीक पहले आधिकारिक निर्णय लेता है।

पार्टनर इंटीग्रेशन के लिए, सबसे मजबूत पॉलिसी नॉर्मलाइज़्ड स्कीम, होस्टनेम और पोर्ट की एक सटीक अनुमति सूची है, वैकल्पिक रूप से अपेक्षित पाथ्स के साथ। यह प्रिव्यू प्रोडक्ट जानबूझकर आर्बिट्रेरी पब्लिक होस्ट्स को स्वीकार करता है। इसलिए इसकी पॉलिसी केवल पब्लिक और विश्व स्तर पर पहुंच योग्य के रूप में वर्गीकृत डेस्टिनेशन्स की अनुमति देती है। आधिकारिक एड्रेस रजिस्ट्रियों और संगठन की अपनी नेटवर्क इन्वेंट्री से क्लासिफ़ायर को बनाए रखें। केवल RFC 1918 सीमाओं वाली हस्तलिखित सूची लूपबैक, लिंक-लोकल, शेयर्ड, मल्टीकास्ट, रिज़र्व्ड, डॉक्यूमेंटेशन, IPv6 यूनिक-लोकल, IPv4-मैप्ड फ़ॉर्म्स और प्रोवाइडर-विशिष्ट मेटाडेटा एंडपॉइंट्स को मिस कर देती है।

स्टेप 2: पहले पार्स करें और पार्स किए गए फ़ील्ड्स से पॉलिसी निर्णय लें

प्लेटफ़ॉर्म के WHATWG-संगत या समान रूप से अच्छी तरह से परखे गए URL पार्सर का उपयोग करें। एक एब्सोल्यूट URL की आवश्यकता रखें। पार्स त्रुटियों, यूज़रनेम या पासवर्ड कॉम्पोनेन्ट, फ़्रैग्मेंट्स (यदि प्रोडक्ट के पास उन्हें रखने का कोई कारण नहीं है), नॉन-HTTP स्कीम्स और स्पष्ट पॉलिसी के बाहर के पोर्ट्स को अस्वीकार करें। अंतर्राष्ट्रीयकृत नामों सहित पार्सर के माध्यम से होस्टनेम को नॉर्मलाइज़ करें, और रॉ स्ट्रिंग को कभी भी regex के साथ अलग से दोबारा व्याख्यायित न करें।

https://expected.example@evil.example/ जैसे उदाहरण दिखाते हैं कि प्रीफ़िक्स मिलान क्यों असुरक्षित है: नेटवर्क होस्ट evil.example है। एक फ़्रैग्मेंट नेटवर्क डेस्टिनेशन का चयन नहीं करता है, और एन्कोडिंग या वैकल्पिक संख्यात्मक रूप एक वैलिडेटर और एक HTTP क्लाइंट के बीच असहमति पैदा कर सकते हैं। एक पार्सर को बाद के प्रत्येक चरण द्वारा उपयोग की जाने वाली स्कीम, कैनोनिकल होस्ट, प्रभावी पोर्ट और रिक्वेस्ट पाथ की आपूर्ति करनी चाहिए।

यदि होस्ट एक IP लिटरल है, तो उसे तुरंत कैनोनिकलाइज़ और क्लासिफ़ाई करें। दोनों परिवारों की नीतियों को लागू करने से पहले IPv4-मैप्ड IPv6 को उसके एम्बेडेड IPv4 मान में बदलें। विराम चिह्नों, स्ट्रिंग की लंबाई या होस्ट डोमेन "जैसा दिखता है" या नहीं, इससे सुरक्षा का अनुमान न लगाएं।

स्टेप 3: प्रत्येक एड्रेस को रिज़ॉल्व करें और कनेक्शन को स्वीकृत परिणाम से बांधें

होस्टनेम के लिए, नियंत्रित रिज़ॉल्वर के साथ A और AAAA दोनों रिकॉर्ड रिज़ॉल्व करें। रिज़ॉल्वर के सामान्य CNAME प्रोसेसिंग का पालन करें और अंतिम एड्रेस एकत्र करें। यदि कोई भी उत्तर अस्वीकृत है तो यह प्रॉम्प्ट डेस्टिनेशन को अस्वीकार करता है। प्रत्येक एड्रेस IP लिटरल के समान क्लासिफ़ायर पास करता है। इसे अस्वीकार करते समय एक रीज़न कोड रिकॉर्ड करें, न कि पूर्ण क्वेरी-युक्त URL।

महत्वपूर्ण इनवेरिएंट यह है:

the IP authorized by policy == the IP used by connect()

एक स्वीकृत एड्रेस चुनें और वही सटीक एड्रेस सॉकेट लेयर को दें। HTTP Host हेडर और HTTPS के लिए TLS SNI और सर्टिफ़िकेट होस्टनेम वेरिफिकेशन के लिए नॉर्मलाइज़्ड होस्टनेम को सुरक्षित रखें। संख्यात्मक IP के लिए मान्य सर्टिफ़िकेट इसका विकल्प नहीं है। HTTP क्लाइंट के स्वतंत्र DNS लुकअप को अक्षम करें; अन्यथा एक अटैकर वैलिडेशन के दौरान एक पब्लिक एड्रेस और कनेक्शन के दौरान एक प्राइवेट एड्रेस लौटा सकता है।

पॉलिसी-अवेयर इग्रेस प्रॉक्सी प्रत्येक वर्कर के बजाय रिज़ॉल्यूशन, क्लासिफिकेशन और कनेक्शन पिनिंग का स्वामित्व ले सकता है। वर्कर उस प्रॉक्सी को नॉर्मलाइज़्ड URL और फिक्स्ड रिक्वेस्ट पॉलिसी भेजता है, न कि अटैकर द्वारा चुने गए प्रॉक्सी एड्रेस को। उसी कॉम्पोनेन्ट को ऑथराइजेशन और सॉकेट का निर्णय लेना चाहिए, या एक कड़ाई से नियंत्रित बाउंड्री के पार छेड़छाड़-रोधी (tamper-resistant) स्वीकृत-एड्रेस परिणाम पास करना चाहिए।

DNS आंसर्स वैध रूप से रोटेट हो सकते हैं, इसलिए पिनिंग हमेशा के लिए नहीं, बल्कि केवल एक फेच हॉप के लिए रहती है। बाद का जॉब, रीडायरेक्ट या स्पष्ट पुनः प्रयास फिर से रिज़ॉल्व और ऑथराइज़ करता है। कनेक्शन पूलिंग को ऑथराइज़्ड ओरिजिन और पॉलिसी द्वारा कीड (keyed) किया जाना चाहिए; सॉकेट का कभी भी केवल इसलिए पुन: उपयोग न करें क्योंकि एक अनट्रस्टेड URL स्ट्रिंग समान दिखाई देती है।

स्टेप 4: प्रत्येक रीडायरेक्ट को एक नए आउटबाउंड रिक्वेस्ट के रूप में मानें

ऑटोमैटिक रीडायरेक्ट फ़ॉलोइंग बंद करें। रीडायरेक्ट स्टेटस वाले प्रत्येक रिस्पॉन्स के लिए, उसी पार्सर का उपयोग करके वर्तमान URL के विरुद्ध Location को रिज़ॉल्व करें, हॉप काउंट बढ़ाएं, और स्कीम, पोर्ट, यूज़रइन्फ़ो, DNS, एड्रेस और कनेक्शन चेक्स को रीस्टार्ट करें। अनुपलब्ध या विकृत लोकेशन्स, लूप्स, चौथे रीडायरेक्ट और किसी भी ऐसे हॉप को अस्वीकार करें जो किसी अस्वीकृत एड्रेस पर रिज़ॉल्व होता है।

पहले होस्ट को कॉलर कुकीज़, ऑथराइजेशन हेडर या आर्बिट्रेरी हेडर फ़ॉरवर्ड न करें। रिस्पॉन्स-सेट क्रेडेंशियल्स को किसी भिन्न ओरिजिन पर फ़ॉरवर्ड न करें। फ़ेचर एक फिक्स्ड User-Agent और एक छोटे फिक्स्ड हेडर सेट का उपयोग करता है। चूंकि प्रोडक्ट को केवल एक टाइटल की आवश्यकता होती है, इसलिए GET पर्याप्त है; रीडायरेक्ट्स को ऑपरेशन को बॉडी वाले कॉलर-नियंत्रित POST में नहीं बदलना चाहिए।

यह एक सामान्य बाईपास को बंद करता है: एक पब्लिक अटैकर-नियंत्रित URL http://169.254.169.254/, http://127.0.0.1/, या किसी इंटरनल सर्विस पर रीडायरेक्ट लौटाता है। केवल पहले URL को स्वीकृत करने से वास्तव में संपर्क किए गए डेस्टिनेशन के अलावा किसी भिन्न अंतिम डेस्टिनेशन को ऑथराइज़ किया जाएगा।

स्टेप 5: नेटवर्क से वह अस्वीकार करवाएं जो एप्लिकेशन कोड से छूट जाता है

फेच वर्कर्स को एक समर्पित नेटवर्क सेगमेंट या नेमस्पेस में चलाएं। इसका इग्रेस फ़ायरवॉल केवल नियंत्रित रिज़ॉल्वर के लिए DNS और केवल पॉलिसी-अवेयर प्रॉक्सी या स्वीकृत पब्लिक रूट के माध्यम से HTTP/HTTPS की अनुमति देता है। यह दोनों IP परिवारों के लिए लूपबैक एस्केप, इंटरनल सर्विस रेंज, क्लस्टर नेटवर्क, कॉर्पोरेट नेटवर्क, लिंक-लोकल स्पेस और क्लाउड मेटाडेटा एंडपॉइंट्स को अस्वीकार करता है। न केवल लिखित नियमों, बल्कि प्रभावी रूट्स को भी वैलिडेट करें।

वर्कर की सर्विस आइडेंटिटी के पास केवल प्रिव्यू जॉब्स को पढ़ने और पूरा करने के लिए आवश्यक अनुमतियां होती हैं। इसके परिवेश में व्यापक क्लाउड क्रेडेंशियल्स रखने से बचें। EC2 पर, अप्रयुक्त होने पर इंस्टेंस मेटाडेटा को अक्षम करना या IMDSv2 की आवश्यकता होने से एक्सपोज़र कम हो जाता है; AWS IPv4 मेटाडेटा एंडपॉइंट 169.254.169.254 और वैकल्पिक IPv6 एंडपॉइंट दोनों का दस्तावेज़ीकरण करता है। ये नियंत्रण डिफेंस इन डेप्थ जोड़ते हैं और URL पॉलिसी को वैकल्पिक नहीं बनाते हैं।

इंटरनल वेबहुक या एडमिनिस्ट्रेशन क्लाइंट्स से एक अलग वर्कर पूल का उपयोग करें। एक जेनेरिक HTTP हेल्पर जो प्राइवेट सर्विसेज़ तक पहुँच सकता है, उसे अनट्रस्टेड URLs को भी प्रोसेस नहीं करना चाहिए। नेटवर्क-अस्वीकृत प्रयासों, जिसमें मेटाडेटा डेस्टिनेशन्स भी शामिल हैं, को कॉलर के सामने इंटरनल टोपोलॉजी को उजागर किए बिना मेट्रिक्स और अलर्ट्स उत्पन्न करने चाहिए।

स्टेप 6: फेच को सीमित करें और केवल वादा किए गए आर्टिफ़ैक्ट को पार्स करें

अलग-अलग DNS, कनेक्ट, फ़र्स्ट-बाइट, आइडल-रीड और कुल तीन-सेकंड की समय सीमा लागू करें। रिस्पॉन्स को स्ट्रीम करें और डीकंप्रेस की गई सामग्री के 2 MiB के बाद रुकें; केवल कंप्रेस्ड-बॉडी सीमा एक डीकंप्रेशन बम की अनुमति देती है। केवल HTML टाइटल के लिए आवश्यक कंटेंट टाइप्स स्वीकार करें। प्रति अकाउंट और वैश्विक स्तर पर कॉनकरेंसी को सीमित करें ताकि कई धीमे पब्लिक सर्वर्स प्रत्येक वर्कर का उपभोग न कर सकें।

अपने आप पुनः प्रयास न करें। पुनः प्रयास एक अन्य आउटबाउंड ऑथराइजेशन बनाता है और लोड को बढ़ा सकता है। यदि प्रोडक्ट आवश्यकताएं बाद में पुनः प्रयास जोड़ती हैं, तो प्रत्येक प्रयास पार्सिंग और रिज़ॉल्यूशन से शुरू होता है और जॉब के कुल बजट के अंदर रहता है।

पार्सर बॉडी को शत्रुतापूर्ण (hostile) मानता है। यह जावास्क्रिप्ट निष्पादित नहीं करता है, XML एक्सटर्नल एंटिटीज़ को रिज़ॉल्व नहीं करता है, इमेजेस, स्टाइलशीट्स, फ़ॉन्ट्स, iframes या स्क्रिप्ट्स लोड नहीं करता है, या मेटाडेटा रीफ़्रेश निर्देशों का पालन नहीं करता है। टाइटल को बाउंडेड स्ट्रीमिंग या आइसोलेटेड पार्सर के साथ निकालें, इसे टेक्स्ट के रूप में नॉर्मलाइज़ करें, इसकी लंबाई सीमित करें, और केवल वही मान लौटाएं। रॉ HTML को API रिस्पॉन्स से बाहर रखें और अंतिम रेंडरिंग सिंक पर टाइटल को एस्केप करें।

स्टेप 7: निर्णयों को ऑब्ज़र्व करें और सॉकेट-लेवल इनवेरिएंट का परीक्षण करें

जॉब परिणाम, नॉर्मलाइज़्ड होस्ट या प्राइवेसी-प्रिजर्विंग होस्ट की, स्कीम, प्रभावी पोर्ट, चयनित एड्रेस क्लास, रीडायरेक्ट काउंट, बाइट्स, अवधि और एक स्थिर अस्वीकृति कारण रिकॉर्ड करें। पूर्ण URL, क्वेरी स्ट्रिंग, यूज़रइन्फ़ो, रिस्पॉन्स बॉडी या DNS पेलोड को लॉग न करें क्योंकि URLs में सीक्रेट्स हो सकते हैं। प्राइवेट, लिंक-लोकल, मेटाडेटा, स्कीम, पोर्ट, रीडायरेक्ट, साइज़, टाइमआउट और कंटेंट-टाइप नियमों के लिए अस्वीकृति दरों को ट्रैक करें।

वास्तविक रिज़ॉल्वर, प्रॉक्सी, फ़ायरवॉल और HTTP क्लाइंट के माध्यम से परीक्षण करें। इसमें शामिल करें:

• लूपबैक वेरिएंट्स जैसे 127.1, IPv6 ::1, और IPv4-मैप्ड IPv6;
• प्राइवेट, शेयर्ड, लिंक-लोकल, मल्टीकास्ट, रिज़र्व्ड, डॉक्यूमेंटेशन और मेटाडेटा एड्रेस;
• एक पब्लिक और एक प्राइवेट उत्तर वाले डोमेन, साथ ही A और AAAA दोनों रिकॉर्ड्स;
• एक रिज़ॉल्वर जो वैलिडेशन के दौरान पब्लिक और अगले लुकअप पर प्राइवेट लौटाता है;
• एक पब्लिक एंडपॉइंट जो प्रत्येक अस्वीकृत एड्रेस फ़ैमिली पर रीडायरेक्ट करता है और एक जो चार बार लूप करता है;
• एम्बेडेड क्रेडेंशियल्स, एन्कोडेड होस्ट्स, नॉन-HTTP स्कीम्स, वर्जित पोर्ट्स और विकृत URLs;
• स्लो हेडर्स, रुके हुए बॉडीज़, ओवरसाइज़्ड डीकंप्रेस्ड बॉडीज़ और कंप्रेस्ड बॉम्ब्स;
• एक HTML पेज जिसकी स्क्रिप्ट या इमेज किसी इंटरनल होस्ट की ओर इशारा करती है;
• एक वैध पब्लिक HTTPS पेज जिसका सॉकेट पिन किया गया है जबकि TLS मूल होस्टनेम को सत्यापित करता है;
• एक जानबूझकर किया गया एप्लिकेशन-पॉलिसी बाईपास जिसे इग्रेस फ़ायरवॉल अभी भी ब्लॉक करता है।

यदि क्लाइंट दूसरा लुकअप करता है तो DNS-रीबाइंडिंग टेस्ट विफल होना चाहिए। सकारात्मक TLS परीक्षण विफल होना चाहिए यदि सर्टिफ़िकेट वेरिफिकेशन गलती से संख्यात्मक IP को टारगेट करता है। साथ में वे साबित करते हैं कि वैलिडेशन और कनेक्शन इच्छित पहचान का उपयोग करते हैं।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं SSRF की रोकथाम को सॉकेट खोलने वाले कॉम्पोनेन्ट द्वारा निष्पादित आउटबाउंड ऑथराइजेशन के रूप में मॉडल करूँगा। API कॉलर को ऑथेंटिकेट और रेट-लिमिट करता है, URL को अनट्रस्टेड इनपुट के रूप में स्टोर करता है, और एक जॉब को कतारबद्ध करता है। फेच वर्कर इसे एक मानक-आधारित पार्सर के साथ पार्स करता है, यूज़रइन्फ़ो, नॉन-HTTP स्कीम्स, और 80 और 443 के बाहर के पोर्ट्स को अस्वीकार करता है, और केवल उस पार्सर से कैनोनिकल होस्ट और पाथ लेता है।

IP लिटरल के लिए, मैं इसे कैनोनिकलाइज़ करता हूँ, IPv4-मैप्ड IPv6 को अनरैप करता हूँ, और एक मेंटेन किया गया पब्लिक-एड्रेस क्लासिफ़ायर लागू करता हूँ। होस्टनेम के लिए, मैं एक नियंत्रित रिज़ॉल्वर के माध्यम से सभी A और AAAA उत्तरों को रिज़ॉल्व करता हूँ और यदि कोई परिणाम प्राइवेट, लूपबैक, शेयर्ड, लिंक-लोकल, मल्टीकास्ट, रिज़र्व्ड, डॉक्यूमेंटेशन, मेटाडेटा या अन्यथा पॉलिसी से बाहर है, तो पूरे डेस्टिनेशन को अस्वीकार कर देता हूँ। फिर मैं Host, TLS SNI और सर्टिफ़िकेट वेरिफिकेशन के लिए मूल होस्टनेम को सुरक्षित रखते हुए सीधे एक स्वीकृत IP से जुड़ता हूँ। यह रीबाइंडिंग हमलों द्वारा उपयोग किए जाने वाले दूसरे-DNS-लुकअप विंडो को हटा देता है।

ऑटोमैटिक रीडायरेक्ट्स और पुनः प्रयास अक्षम हैं। तीन रीडायरेक्ट्स तक मैं नए लोकेशन को पार्स करता हूँ और दूसरा सॉकेट खोलने से पहले पूर्ण ऑथराइजेशन दोहराता हूँ। मैं केवल फिक्स्ड हेडर्स के साथ GET भेजता हूँ और कोई कॉलर कुकीज़ या क्रेडेंशियल्स नहीं भेजता हूँ। एक समर्पित इग्रेस प्रॉक्सी या फ़ायरवॉल IPv4 और IPv6 पर प्रत्येक इंटरनल, क्लस्टर, कॉर्पोरेट, लिंक-लोकल और मेटाडेटा रूट को अलग से अस्वीकार करता है। वर्कर के पास एक न्यूनतम सर्विस आइडेंटिटी होती है और वह सामान्य इंटरनल HTTP क्लाइंट का उपयोग नहीं कर सकता है।

प्रत्येक जॉब में तीन-सेकंड की कुल समय सीमा और 2 MiB डीकंप्रेस्ड-बॉडी कैप होती है। पार्सर कोई स्क्रिप्ट निष्पादित नहीं करता है और कोई सब-रिसोर्स लोड नहीं करता है; यह केवल एक लंबाई-सीमित, सैनिटाइज़्ड टाइटल लौटाता है। मैं पूर्ण URLs के बिना रीज़न कोड्स, एड्रेस क्लास, रीडायरेक्ट काउंट, बाइट्स और लेटेंसी लॉग करता हूँ। मेरे स्वीकृति सुइट में मिक्स्ड DNS आंसर्स, चेक और कनेक्ट के बीच रीबाइंडिंग, IPv4-मैप्ड IPv6, रीडायरेक्ट-टू-मेटाडेटा, gzip बॉम्ब्स, स्लो बॉडीज़, सॉकेट-पिन किया गया TLS, और एक पॉलिसी बाईपास शामिल है जिसे नेटवर्क द्वारा अभी भी रोका जाना चाहिए।"

सामान्य गलतियाँ

• केवल localhost और RFC 1918 को ब्लॉक करना → वैकल्पिक IPv4 फ़ॉर्म्स, IPv6, लिंक-लोकल, शेयर्ड, रिज़र्व्ड और मेटाडेटा एड्रेस सुलभ रहते हैं → मेंटेन की गई पब्लिक-डेस्टिनेशन पॉलिसी के साथ दोनों एड्रेस परिवारों को कैनोनिकलाइज़ और क्लासिफ़ाई करें।
• Regex के साथ वैलिडेट करना → वैलिडेटर और HTTP पार्सर क्रेडेंशियल्स, एन्कोडिंग, होस्ट और पोर्ट के बारे में असहमत हो सकते हैं → एक मानक-आधारित पार्सर का उपयोग करें और केवल इसके कैनोनिकल फ़ील्ड्स का उपभोग करें।
• रिज़ॉल्व करना, जांचना, फिर क्लाइंट को फिर से रिज़ॉल्व करने देना → DNS रीबाइंडिंग अनुमोदन के बाद सॉकेट डेस्टिनेशन को बदल देती है → होस्टनेम के विरुद्ध TLS सत्यापित करते हुए कनेक्शन को जाँचे गए IP पर पिन करें।
• केवल पहले URL को स्वीकृत करना → एक अनुमत पब्लिक होस्ट एक इंटरनल सर्विस पर रीडायरेक्ट कर सकता है → ऑटोमैटिक रीडायरेक्ट्स को अक्षम करें और प्रत्येक हॉप को पुनः ऑथराइज़ करें।
• मिक्स्ड DNS परिणामों से सुरक्षित उत्तर चुनना → एक एड्रेस-चयन परिवर्तन बाद में असुरक्षित उत्तर तक पहुँच सकता है → जब कोई भी लौटाया गया एड्रेस इस प्रॉम्प्ट की पॉलिसी का उल्लंघन करता है तो होस्टनेम को अस्वीकार करें।
• कॉलर हेडर्स को फ़ॉरवर्ड करना → कुकीज़ या ऑथराइजेशन मान अटैकर-चयनित होस्ट को लीक हो जाते हैं → बिना किसी एम्बिएंट क्रेडेंशियल्स के एक फिक्स्ड आउटबाउंड रिक्वेस्ट का निर्माण करें।
• अकेले IMDSv2 या क्लाउड सेटिंग पर निर्भर रहना → इंटरनल सर्विसेज़ और अन्य एड्रेस रेंज एक्सपोज़्ड रहती हैं → एप्लिकेशन ऑथराइजेशन, न्यूनतम पहचान, मेटाडेटा हार्डनिंग और इग्रेस डिनायल को संयोजित करें।
• केवल कंप्रेस्ड बाइट्स को सीमित करना → एक छोटी बॉडी तब तक फैल सकती है जब तक कि मेमोरी या CPU समाप्त न हो जाए → डीकंप्रेस्ड बाइट्स, पार्सिंग कार्य, समय और कॉनकरेंसी को सीमित करें।
• पेज को ब्राउज़र की तरह पार्स करना → स्क्रिप्ट्स और सब-रिसोर्स नए असमीक्षित आउटबाउंड रिक्वेस्ट बनाते हैं → सक्रिय सामग्री और एक्सटर्नल एंटिटी रिज़ॉल्यूशन अक्षम करके केवल वादा किए गए आर्टिफ़ैक्ट को निकालें।
• डीबगिंग के लिए पूर्ण URLs लॉग करना → क्वेरी सीक्रेट्स और क्रेडेंशियल्स ऑब्ज़र्वेबिलिटी सिस्टम्स में चले जाते हैं → बाउंडेड कैनोनिकल फ़ील्ड्स और स्थिर रीज़न कोड्स लॉग करें।

फॉलो-अप प्रश्न

क्या बदलता है जब प्रत्येक डेस्टिनेशन एक ज्ञात पार्टनर होता है?

नॉर्मलाइज़्ड स्कीम, होस्टनेम और पोर्ट की एक सटीक अनुमति सूची का उपयोग करें और इसे समीक्षित कॉन्फ़िगरेशन के माध्यम से प्रोविज़न करें। वैसे भी एड्रेस को रिज़ॉल्व और क्लासिफ़ाई करें: एक कॉम्प्रोमाइज़्ड DNS रिकॉर्ड या कॉन्फ़िगरेशन गलती को एक ट्रस्टेड नाम को इंटरनल रूट में नहीं बदलना चाहिए। एक प्राइवेट पार्टनर एंडपॉइंट एक स्पष्ट नेटवर्क पाथ के साथ एक अलग ऑथेंटिकेटेड इंटीग्रेशन से संबंधित है, न कि पब्लिक प्रिव्यू वर्कर में।

क्या सर्विस सुरक्षित रूप से डोमेन में रीडायरेक्ट्स का समर्थन कर सकती है?

हाँ, यदि क्रॉस-डोमेन रीडायरेक्ट्स एक प्रोडक्ट आवश्यकता हैं और प्रत्येक हॉप पूरी पॉलिसी को दोहराता है। क्रेडेंशियल्स और ओरिजिन-विशिष्ट स्थिति को स्ट्रिप करें, नए होस्टनेम को रिज़ॉल्व करें, प्रत्येक परिणाम को क्लासिफ़ाई करें, नए कनेक्शन को पिन करें, और हॉप की गणना करें। एक सरल नीति समान ओरिजिन की मांग कर सकती है, लेकिन यह सामान्य पब्लिक रीडायरेक्टर्स को अस्वीकार करती है; इंटरव्यूअर को उस प्रोडक्ट ट्रेडऑफ़ को स्पष्ट रूप से सुनना चाहिए।

जब एक DNS उत्तर पब्लिक और दूसरा प्राइवेट हो तो होस्टनेम को क्यों अस्वीकार करें?

यह एक स्थिर फ़ेल-क्लोज़्ड अनुबंध बनाता है। रिज़ॉल्वर, IP परिवारों और पुनः प्रयासों में एड्रेस का क्रम भिन्न होता है। वैलिडेशन के दौरान एक पब्लिक उत्तर का चयन करना जबकि दूसरा कॉम्पोनेन्ट बाद में प्राइवेट उत्तर का चयन करता है, गैप को फिर से खोल देता है। जो प्रोडक्ट आंशिक स्वीकृति चाहता है, उसे प्रत्येक कनेक्शन के लिए केवल स्वीकृत एड्रेस को पिन करने के लिए उसी कॉम्पोनेन्ट की आवश्यकता होती है और उसे फ़ेलओवर का सावधानीपूर्वक परीक्षण करना चाहिए; यह प्रॉम्प्ट सरल रूढ़िवादी पॉलिसी लेता है।

क्या होगा यदि प्रोडक्ट को स्क्रीनशॉट या जावास्क्रिप्ट-रेंडर किए गए प्रिव्यू की आवश्यकता हो?

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

आप डिप्लॉयमेंट के बाद यह कैसे साबित करेंगे कि फ़ायरवॉल प्रभावी है?

अस्वीकृत IPv4, IPv6, क्लस्टर, कॉर्पोरेट और मेटाडेटा डेस्टिनेशन्स के विरुद्ध वास्तविक वर्कर पहचान और नेमस्पेस से नियंत्रित कैनरीज़ चलाएं, फिर कनेक्शन विफलता और अपेक्षित नेटवर्क टेलीमेट्री दोनों की पुष्टि करें। रूट, कंटेनर, प्रॉक्सी या क्लाउड-नेटवर्क परिवर्तनों के बाद दोहराएं। कॉन्फ़िगरेशन समीक्षा इरादा दिखाती है; कैनरीज़ और फ़्लो लॉग प्रभावी पाथ दिखाते हैं।