Browser HTTP Request Smuggling

Reading time: 3 minutes

Browser-powered desync (या client-side request smuggling) पीड़ित के ब्राउज़र का दुरुपयोग करता है ताकि एक गलत-फ्रेम वाला अनुरोध एक साझा कनेक्शन पर एंकीट किया जा सके, ताकि बाद के अनुरोधों को एक डाउनस्ट्रीम घटक द्वारा असंगत रूप से पार्स किया जा सके। क्लासिक FE↔BE smuggling के विपरीत, पेलोड्स उस परिधि द्वारा सीमित होते हैं जो एक ब्राउज़र कानूनी रूप से क्रॉस-ओरिजिन भेज सकता है।

मुख्य सीमाएँ और सुझाव

• केवल उन हेडर और सिंटैक्स का उपयोग करें जो एक ब्राउज़र नेविगेशन, फेच, या फॉर्म सबमिशन के माध्यम से उत्पन्न कर सकता है। हेडर ओबफस्केशन्स (LWS ट्रिक्स, डुप्लिकेट TE, अवैध CL) सामान्यतः नहीं भेजे जाएंगे।
• उन अंत बिंदुओं और मध्यवर्ती को लक्षित करें जो इनपुट को दर्शाते हैं या प्रतिक्रियाओं को कैश करते हैं। उपयोगी प्रभावों में कैश पॉइज़निंग, फ्रंट-एंड इंजेक्टेड हेडर का लीक होना, या फ्रंट-एंड पथ/विधि नियंत्रणों को बायपास करना शामिल है।
• पुन: उपयोग महत्वपूर्ण है: तैयार किए गए अनुरोध को इस तरह से संरेखित करें कि यह एक उच्च-मूल्य वाले पीड़ित अनुरोध के समान HTTP/1.1 या H2 कनेक्शन को साझा करे। कनेक्शन-लॉक्ड/स्टेटफुल व्यवहार प्रभाव को बढ़ाते हैं।
• उन प्राइमिटिव्स को प्राथमिकता दें जिन्हें कस्टम हेडर की आवश्यकता नहीं होती: पथ भ्रम, क्वेरी-स्ट्रिंग इंजेक्शन, और फॉर्म-कोडेड POST के माध्यम से बॉडी शेपिंग।
• वास्तविक सर्वर-साइड डीसिंक की पुष्टि करें बनाम केवल पाइपलाइनिंग आर्टिफैक्ट्स द्वारा पुन: परीक्षण करके, या HTTP/2 नेस्टेड-रिस्पॉन्स चेक का उपयोग करके।

अंत-से-अंत तकनीकों और PoCs के लिए देखें:

• PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync

References

• https://portswigger.net/research/browser-powered-desync-attacks
• https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
• पाइपलाइनिंग बनाम स्मगलिंग का अंतर (पुन: उपयोग झूठे सकारात्मक पर पृष्ठभूमि): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling