संकेत और दायरा
एक एप्लिकेशन CDN, रिवर्स प्रॉक्सी, WAF और बैकएंड सर्विस के पीछे स्थित है। सुरक्षा टीम पाती है कि घटक एक ही HTTP/1.1 बाइट स्ट्रीम में अनुरोध सीमा (request boundary) पर असहमत हैं, जिससे फ्रंट एंड को एक अनुरोध दिखाई देता है जबकि बैकएंड बचे हुए बाइट्स से दूसरे अनुरोध को पार्स करता है। इस तंत्र, परस्पर विरोधी Content-Length और Transfer-Encoding के सुरक्षित संचालन, पहचान, समाधान, सत्यापन और रोलआउट की व्याख्या करें।
RFC 9112 चेतावनी देता है कि प्राप्तकर्ताओं के बीच अलग-अलग रोबस्टनेस नियम रिक्वेस्ट-स्मगलिंग का जोखिम पैदा कर सकते हैं। OWASP इस श्रेणी का कारण फ्रंट-एंड और बैक-एंड घटकों के बीच असंगत पार्सिंग को मानता है। यह प्रश्न यह परखता है कि क्या आप किसी हमले के संक्षिप्त नाम को रटने के बजाय "पार्सर असहमति" को बाइट स्ट्रीम, कनेक्शन पुनर्चक्रण (connection reuse), और सुरक्षा सीमाओं के संदर्भ में समझा सकते हैं।
साक्षात्कारकर्ता क्या जांच रहा है
- मैसेज फ्रेमिंग, रूटिंग और एप्लिकेशन-पैरामीटर सत्यापन को अलग करना।
Content-Length,Transfer-Encoding, और HTTP/1.0 डाउनग्रेड सीमाओं को सही ढंग से समझाना।- यह पहचानना कि कौन सा प्रॉक्सी पार्स करता है, कौन सा कनेक्शन पुन: उपयोग किया जाता है, और बचे हुए बाइट्स अगले अनुरोध को कैसे प्रभावित करते हैं।
- अस्पष्ट अनुरोधों को अस्वीकार करने, एक सख्त पार्सर का उपयोग करने और कनेक्शन बंद करने का संयोजन।
- प्रोडक्शन पर बिना किसी दुष्प्रभाव के सुरक्षित परीक्षण, निगरानी, कैनरी और रोलबैक डिजाइन करना।
- HTTP/2 या HTTP/3 का उपयोग होने पर भी अनुवाद परतों (translation layers) की जांच करना।
स्पष्टीकरण हेतु प्रश्न
- पथ में कौन से HTTP संस्करण और मिडलवेयर मौजूद हैं? एक HTTP/1.1 प्रॉक्सी और बैकएंड पूल मान लें।
- क्या फ्रंट और बैक एंड TCP कनेक्शन का पुन: उपयोग कर रहे हैं? स्मगलिंग आमतौर पर पुन: उपयोग या भिन्न पार्सर स्थिति पर निर्भर करती है।
- क्या चंक्ड बॉडी और रिक्वेस्ट बॉडी की अनुमति है? मान लें कि सार्वजनिक एज इसकी अनुमति देता है लेकिन अस्पष्ट संयोजनों को अस्वीकार कर सकता है।
- क्या लक्ष्य तत्काल नियंत्रण है या स्थायी पार्सर एकरूपता? दोनों प्रदान करें।
- क्या परीक्षण एक अलग (isolated) बैकएंड और दुष्प्रभाव-रहित एंडपॉइंट का उपयोग कर सकता है? इसे प्रोडक्शन में विनाशकारी ट्रैफ़िक भेजने के बजाय ऐसा ही करना चाहिए।
तीस सेकंड का उत्तर
मैं प्रॉक्सी से बैकएंड तक बाइट स्ट्रीम और कनेक्शन पुन: उपयोग का चित्र बनाऊंगा। इसका मूल कारण विभिन्न प्राप्तकर्ताओं द्वारा संदेश की लंबाई निर्धारित करने के लिए अलग-अलग नियमों का उपयोग करना है, विशेष रूप से तब जब Content-Length और Transfer-Encoding दोनों मौजूद हों या अमान्य डुप्लिकेट लंबाई दिखाई दे। एज अस्पष्टता को अस्वीकार करता है, सख्ती से पार्स करता है, त्रुटियों पर कनेक्शन बंद करता है, और प्रॉक्सी तथा बैकएंड कार्यान्वयन को संरेखित रखता है। मैं एक अलग एंडपॉइंट और दो-घटक तुलना के साथ सत्यापन करूंगा, फिर रिवर्सिबल रूट के साथ कैनरी के दौरान असामान्य 400s, रीसेट, पार्सर त्रुटियों और अनुरोध-संख्या विसंगतियों की निगरानी करूंगा।
चरण-दर-चरण समाधान
चरण 1: मैसेज और कनेक्शन सीमाओं को चित्रित करें
सूचीबद्ध करें कि क्या क्लाइंट, CDN, WAF, रिवर्स प्रॉक्सी और बैकएंड अनुरोधों को पार्स करते हैं, हेडर को फिर से लिखते हैं, या अपस्ट्रीम कनेक्शन का पुन: उपयोग करते हैं। HTTP/1.1 एक बाइट-स्ट्रीम प्रोटोकॉल है; प्रत्येक प्राप्तकर्ता हेडर फ़ील्ड से बॉडी की लंबाई प्राप्त करता है। यदि दो परतें असहमत होती हैं, तो बचे हुए बाइट्स अगली परत पर एक नया अनुरोध बन सकते हैं।
पेलोड से शुरुआत न करें। एक हानिरहित बाइट-स्ट्रीम उदाहरण का उपयोग करें जो दिखाता है कि फ्रंट एंड एक अनुरोध पढ़ता है जबकि बैकएंड दो अनुरोध पढ़ता है, ताकि सीमा की स्थिति स्पष्ट हो।
चरण 2: लंबाई के नियमों और अस्पष्टता की व्याख्या करें
RFC 9112 संदेश-बॉडी की लंबाई, Content-Length, और Transfer-Encoding व्यवहार को परिभाषित करता है। जब दोनों मौजूद हों, तो प्राप्तकर्ताओं को स्वतंत्र रूप से किसी एक को चुनकर आगे नहीं बढ़ना चाहिए। अनुरोध को अस्पष्ट मानें और इसे अस्वीकार करें, आमतौर पर कनेक्शन बंद कर दें। परस्पर विरोधी डुप्लिकेट Content-Length फ़ील्ड्स को भी पहले या अंतिम मान को चुनने के बजाय अस्वीकार किया जाना चाहिए।
Transfer-Encoding युक्त HTTP/1.0 अनुरोध को सामान्य चंक्ड सिमेंटिक्स के रूप में नहीं माना जा सकता है। इसे प्रोटोकॉल त्रुटि के रूप में संसाधित करें और आवश्यकतानुसार बंद करें। सिद्धांत प्रत्येक प्राप्तकर्ता के लिए एक सख्त नियम का है, न कि विकृत (malformed) क्लाइंट्स के प्रति "रोबस्ट" सहनशीलता का।
चरण 3: बताएं कि पुन: उपयोग प्रभाव को कैसे बढ़ाता है
फ्रंट प्रॉक्सी एक क्लाइंट कनेक्शन को कई अपस्ट्रीम अनुरोधों में विभाजित कर सकता है, जबकि बैकएंड पूल पुन: उपयोग किए गए कनेक्शन पर अधिक बाइट्स की प्रतीक्षा करता है। यदि सीमाएं भिन्न होती हैं, तो इंजेक्ट किया गया प्रीफिक्स बफर में रहता है और अगले अनुरोध की शुरुआत बन जाता है। कैश, प्रमाणीकरण मार्ग, आंतरिक प्रशासन एंडपॉइंट और अन्य किरायेदार (tenant) के अनुरोध प्रभावित हो सकते हैं।
इसलिए समाधान में CDN, WAF, प्रॉक्सी और प्रोटोकॉल अनुवाद शामिल हैं। जांचें कि क्या पार्स त्रुटि एक पुन: प्रयोज्य कनेक्शन छोड़ती है, क्या बफ़र्स साफ़ किए गए हैं, और क्या HTTP/2 से HTTP/1.1 में अनुवाद करते समय गेटवे सुसंगत लंबाई फ़ील्ड को पुनर्जीवित करता है।
चरण 4: एज नियंत्रण रणनीति दें
ऐसे अनुरोधों को अस्वीकार करें जिनमें Content-Length और Transfer-Encoding दोनों शामिल हों, डुप्लिकेट लंबाई फ़ील्ड हों, अमान्य चंक फ्रेमिंग हो, या असमर्थित संस्करण हों। पार्स त्रुटि के बाद बचे हुए बाइट्स को अगले अनुरोध को सौंपने के बजाय कनेक्शन बंद कर दें। प्रभावित मार्ग पर अपस्ट्रीम पुन: उपयोग को अस्थायी रूप से अक्षम करने से जोखिम नियंत्रित हो सकता है, लेकिन यह विलंबता (latency) और कनेक्शन लागत को बढ़ाता है।
नियमों को स्पष्ट अपवादों और वर्गीकृत लॉग की आवश्यकता होती है; प्रत्येक घटक में अलग-अलग ब्लैकलिस्ट एक और असहमति पैदा करती हैं। वैध क्लाइंट्स के लिए एक साझा सख्त पार्सर संस्करण और संगतता मैट्रिक्स को प्राथमिकता दें।
चरण 5: पार्सिंग को एकरूप करें और हेडर को सामान्यीकृत करें
एक पार्सिंग सीमा पर फ्रेमिंग पूरी करें और एप्लिकेशन को एक संरचित अनुरोध पास करें। एप्लिकेशन को रॉ हेडर्स को फिर से पार्स नहीं करना चाहिए या प्रॉक्सी की "सत्यापित लंबाई" पर भरोसा नहीं करना चाहिए। यदि कोई प्रॉक्सी किसी अनुरोध को फिर से लिखता है, तो अस्पष्ट फ़ील्ड्स को हटा दें और अग्रेषित बॉडी से एक विहित (canonical) लंबाई उत्पन्न करें; डाउनस्ट्रीम को पुराने फ़ील्ड नहीं दिखने चाहिए।
HTTP/2 और HTTP/3 में अलग-अलग फ्रेम परतें होती हैं, लेकिन HTTP/1.1 का गेटवे अस्पष्टता को फिर से बना सकता है। प्रत्येक अनुवाद बिंदु पर हेडर विलय, बॉडी बफरिंग, त्रुटि कनेक्शन प्रबंधन और डाउनग्रेड पथों का ऑडिट करें।
चरण 6: सुरक्षित परीक्षण डिज़ाइन करें
एक अलग वातावरण में, एक फ्रंट प्रॉक्सी को एक इको बैकएंड से पहले रखें जो अनुरोध आईडी, पार्स की गई लंबाई और आगमन क्रम को रिकॉर्ड करता है। परस्पर विरोधी लंबाई, डुप्लिकेट, अमान्य चंक्स, HTTP/1.0 डाउनग्रेड, कनेक्शन पुन: उपयोग, टाइमआउट और प्रॉक्सी पुनः प्रयास (retry) को कवर करें। पुष्टि (assert) करें कि प्रत्येक परत समान अनुरोध संख्या, विधि, पथ और बॉडी की लंबाई देखती है।
प्रोडक्शन में कभी भी ऐसे पेलोड न भेजें जिनके खाते, ऑर्डर या कैश पर दुष्प्रभाव हों। शैडो ट्रैफ़िक, सिंथेटिक कनेक्शन और केवल-पढ़ने योग्य एंडपॉइंट्स का उपयोग करें; यदि वास्तविक पथ की जाँच की जानी है, तो दुष्प्रभावों को अक्षम करें और कनेक्शन-स्तरीय लॉग सुरक्षित रखें।
चरण 7: निगरानी, कैनरी और रोलबैक
पार्सर त्रुटियों, असामान्य 400/431 प्रतिक्रियाओं, रीसेट, अपस्ट्रीम टाइमआउट, पुन: उपयोग किए गए कनेक्शन पर सीमा विसंगतियों और WAF-से-बैकएंड अनुरोध-संख्या अंतरों की निगरानी करें। प्रॉक्सी संस्करण, प्रोटोकॉल, किरायेदार (tenant) और पथ के अनुसार विभाजित करें ताकि एक एज नोड औसत में न छिप जाए।
नए पार्सर को पहले शैडो में या छोटे प्रतिशत पर चलाएं। पार्सर त्रुटियों, वैध-क्लाइंट विफलताओं, या कनेक्शन समाप्त होने में उछाल आने पर रोकें। सुरक्षित अस्पष्ट-अनुरोध अस्वीकृति स्विच को बनाए रखते हुए मार्ग और कॉन्फ़िगरेशन संस्करण को रोलबैक करें; संगतता के लिए उदार (permissive) पार्सिंग की आवश्यकता नहीं होनी चाहिए।
चरण 8: जटिलता और संचार
हेडर और बॉडी को पढ़ते समय फ्रेमिंग मैसेज के आकार के अनुसार रैखिक (linear) होती है। महत्वपूर्ण अनुकूलन माइक्रोसेकंड नहीं है, बल्कि यह सुनिश्चित करना है कि प्रत्येक बाइट एक मानक पार्सिंग सीमा द्वारा उपभोग की जाए। रनबुक में RFC नियम, घटक संस्करण, कनेक्शन नीति और परीक्षण मैट्रिक्स शामिल करें।
गैर-सुरक्षा दर्शकों के लिए, इसकी तुलना एक ही लिफाफे में अलग-अलग तरीकों से पृष्ठों की गिनती करने वाले दो प्राप्तकर्ताओं से करें, फिर ऐसे कार्य दें जिन्हें सत्यापित किया जा सके: अस्पष्टता को अस्वीकार करना, पार्सर्स को एकरूप करना, त्रुटि पर बंद करना, अलग से परीक्षण करना और प्रतिवर्ती रूप से कैनरी करना।
मॉडल उत्तर
रिक्वेस्ट स्मगलिंग एक पार्सर-सीमा समस्या है, न कि कोई एकल एप्लिकेशन-रूट बग। एक फ्रंट एंड Content-Length पर रुक सकता है जबकि बैकएंड Transfer-Encoding के साथ जारी रहता है, जिससे हमलावर द्वारा नियंत्रित बाइट्स पुन: उपयोग किए गए कनेक्शन पर अगले अनुरोध के रूप में छूट जाते हैं। मैं प्रत्येक पार्सर और अनुवाद बिंदु की सूची बनाऊंगा, उन्हें सख्त RFC 9112 व्यवहार पर संरेखित करूंगा, एज पर सह-अस्तित्व वाले लंबाई संकेतों, डुप्लिकेट और अमान्य चंक्स को अस्वीकार करूंगा, और पार्स त्रुटियों के बाद कनेक्शन बंद करूंगा।
मैं परस्पर विरोधी लंबाई, कनेक्शन पुन: उपयोग, पुनः प्रयास और प्रोटोकॉल अनुवाद के साथ प्रॉक्सी के विरुद्ध एक अलग इको बैकएंड का परीक्षण करूंगा, और समान अनुरोध संख्या, पथ और बॉडी लंबाई की पुष्टि करूंगा। पार्सर त्रुटियों, रीसेट, वैध विफलताओं और गणना विसंगतियों की निगरानी करते हुए शैडो मोड और कैनरी में रोल आउट करूंगा। किसी भी उल्लंघन पर मार्ग और संस्करण को रोलबैक किया जाएगा लेकिन अस्पष्ट अनुरोधों की अस्वीकृति जारी रहेगी।
सामान्य गलतियाँ
- बाइट्स और कनेक्शन के पुन: उपयोग को समझाए बिना केवल हमलों के नाम रटना।
- अस्पष्टता को अस्वीकार करने के बजाय "Content-Length को प्राथमिकता दें" या "Transfer-Encoding को प्राथमिकता दें" कहना।
- डुप्लिकेट
Content-Lengthका पहला या अंतिम मान लेना। - केवल एप्लिकेशन को ठीक करना और CDN, WAF, प्रॉक्सी, या अनुवाद परतों की उपेक्षा करना।
- विनाशकारी एंडपॉइंट्स का परीक्षण करना या समान अनुरोध संख्याओं की पुष्टि करने में विफल होना।
- पार्स विफलता के बाद कनेक्शन का पुन: उपयोग करना और बचे हुए बाइट्स को आगे ले जाना।
- यह मान लेना कि HTTP/2 या HTTP/3 गेटवे जोखिम को स्वचालित रूप से हटा देता है।
- कैनरी के दौरान प्रोटोकॉल और क्लाइंट स्लाइस के बजाय केवल समग्र 5xx त्रुटियों पर नज़र रखना।
अनुवर्ती प्रश्न
जब Content-Length और Transfer-Encoding दोनों मौजूद हों तो क्या होना चाहिए?
सख्त पार्सिंग नीति के तहत अस्पष्ट अनुरोध को अस्वीकार करें और आमतौर पर कनेक्शन बंद करें। प्रत्येक प्रॉक्सी और बैकएंड को एक ही नियम लागू करना चाहिए; किसी एक परत को भिन्न फ़ील्ड चुनकर अग्रेषण जारी नहीं रखना चाहिए।
क्या समान डुप्लिकेट Content-Length मानों को भी अस्वीकार किया जाना चाहिए?
डुप्लिकेट को अस्वीकार करना सबसे सुरक्षित क्रॉस-कंपोनेंट नीति है जब तक कि पूरी श्रृंखला में एक प्रलेखित विलय नियम न हो। संगतता को नियंत्रित अनुमति सूची (allowlist) और परीक्षणों के साथ हल करें, स्वतंत्र घटक व्यवहार के साथ नहीं।
आप कैसे साबित करेंगे कि सामान्य क्लाइंट्स प्रभावित नहीं हुए?
वैध क्लाइंट प्रोटोकॉल संस्करणों, बॉडी एन्कोडिंग और प्रॉक्सी पथों की सूची बनाएं। उन्हें अलग वातावरण में रीप्ले और संश्लेषित (synthesize) करें, फिर वैध 4xx, रीसेट और विलंबता की निगरानी करते हुए कैनरी करें। उदार पार्सिंग को फिर से खोलने के बजाय क्लाइंट प्रकार द्वारा रोलबैक या अपग्रेड करें।
क्या HTTP/2 पूरी तरह से प्रतिरक्षित है?
बाइनरी फ्रेमिंग कुछ HTTP/1.1 अस्पष्टता को हटा देती है, लेकिन HTTP/2-से-HTTP/1.1 गेटवे अभी भी हेडर और बॉडी बनाता है। केवल क्लाइंट प्रोटोकॉल पर निर्भर रहने के बजाय अनुवाद, पुन: उपयोग और डाउनस्ट्रीम पार्सिंग का ऑडिट करें।
पार्स त्रुटि के बाद कनेक्शन क्यों बंद करें?
प्राप्तकर्ता यह साबित नहीं कर सकता कि बफर किए गए बाइट्स इस अनुरोध के हैं या अगले के। कनेक्शन बंद करने से अनिश्चित स्थिति समाप्त हो जाती है और पुन: उपयोग किए गए कनेक्शन पर पुनर्व्याख्या को रोका जा सकता है; पुन: कनेक्ट करने की लागत को मापें।
आप स्मगलिंग को कैश पॉइज़निंग से कैसे अलग करते हैं?
स्मगलिंग एक मैसेज-सीमा पार्सिंग विसंगति है; कैश पॉइज़निंग हमलावर द्वारा नियंत्रित प्रतिक्रिया या कुंजी को संग्रहीत करती है। स्मगलिंग पॉइज़निंग को सक्षम कर सकती है, लेकिन पहले फ्रेमिंग और कनेक्शन हैंडलिंग को एकरूप करें, फिर कैश कुंजियों, रूटिंग और प्राधिकरण का अलग से परीक्षण करें।
आप कौन से ऑडिट फ़ील्ड बनाए रखते हैं?
प्रॉक्सी और बैकएंड संस्करण, प्रोटोकॉल, कनेक्शन आईडी, पार्स परिणाम, अस्वीकृति का कारण, एक सामान्यीकृत-हेडर सारांश, अनुरोध आईडी और प्रतिक्रिया स्थिति रिकॉर्ड करें। संवेदनशील बॉडीज़ से बचें; फ़ील्ड्स को प्रत्येक परत के सीमा निर्णय को अंतिम स्थिति से सहसंबद्ध करना चाहिए।