L वेब सिस्टम जहां फ्रंटएंड HTTP / 2 . के माध्यम से कनेक्शन स्वीकार करता है और उन्हें HTTP / 1.1 h . के माध्यम से बैकएंड में भेजता है"HTTP अनुरोध तस्करी" हमले के एक नए संस्करण से अवगत कराया गया है, यह विशेष रूप से डिज़ाइन किए गए क्लाइंट अनुरोधों को भेजकर, अन्य उपयोगकर्ताओं के अनुरोधों की सामग्री को फ्रंटएंड और बैकएंड के बीच समान प्रवाह में विभाजित करने की अनुमति देता है।
हमला दुर्भावनापूर्ण जावास्क्रिप्ट कोड को इंजेक्ट करने के लिए इस्तेमाल किया जा सकता है एक वैध साइट वाले सत्र में, एक्सेस प्रतिबंध प्रणाली को बायपास करें और प्रमाणीकरण पैरामीटर को रोकें।
अध्ययन के लेखक Netflix, Verizon, Bitbucket, Netlify CDN और Atlassian सिस्टम पर हमला करने की संभावना का प्रदर्शन किया, और कमजोरियों की पहचान करने के लिए इनाम कार्यक्रमों में $ 56.000 प्राप्त किए। F5 नेटवर्क उत्पादों में भी समस्या की पुष्टि की गई है।
समस्या Apache http सर्वर पर mod_proxy को आंशिक रूप से प्रभावित करता है (CVE-2021-33193), संस्करण 2.4.49 में अपेक्षित सुधार (डेवलपर्स को मई की शुरुआत में समस्या के बारे में सूचित किया गया था और इसे ठीक करने के लिए 3 महीने प्राप्त हुए थे)। Nginx में, "सामग्री-लंबाई" और "स्थानांतरण-एन्कोडिंग" शीर्षकों को एक साथ निर्दिष्ट करने की क्षमता पिछले संस्करण (1.21.1) में अवरुद्ध कर दी गई थी।
नई पद्धति के संचालन का सिद्धांत ट्रैफ़िक में मिलान अनुरोधों का दो साल पहले उसी शोधकर्ता द्वारा खोजी गई भेद्यता के समान है, लेकिन यह उन इंटरफेस तक सीमित है जो HTTP / 1.1 पर अनुरोध स्वीकार करते हैं।
क्लासिक "HTTP अनुरोध तस्करी" हमला इस तथ्य पर आधारित था कि फ्रंटएंड और बैकएंड HTTP "सामग्री-लंबाई" शीर्षलेखों के उपयोग की अलग-अलग व्याख्या करते हैं (अनुरोध में डेटा के कुल आकार को निर्धारित करते हैं) और "स्थानांतरण-एन्कोडिंग: खंडित" ( आपको डेटा को विखंडू में स्थानांतरित करने की अनुमति देता है) ...
उदाहरण के लिए, यदि इंटरफ़ेस केवल "सामग्री-लंबाई" का समर्थन करता है, लेकिन "स्थानांतरण-एन्कोडिंग: खंडित" को अनदेखा करता है, तो एक हमलावर एक अनुरोध भेज सकता है जिसमें हेडर "सामग्री-लंबाई" और "स्थानांतर-एन्कोडिंग: खंडित" शामिल हैं, लेकिन आकार hi "सामग्री की लंबाई" खंडित स्ट्रिंग के आकार से मेल नहीं खाती है। इस मामले में, फ्रंटएंड "सामग्री की लंबाई" के अनुसार अनुरोध को संसाधित और पुनर्निर्देशित करेगा, और बैकएंड "ट्रांसफर एन्कोडिंग: चंक्ड" के आधार पर ब्लॉक के पूरा होने की प्रतीक्षा करेगा।
टेक्स्ट HTTP / 1.1 प्रोटोकॉल के विपरीत, जिसे लाइन स्तर पर पार्स किया जाता है, HTTP / 2 एक बाइनरी प्रोटोकॉल है और ब्लॉक में हेरफेर करता है पूर्व निर्धारित आकार का डेटा। हालांकि, HTTP / 2 छद्म हेडर का प्रयोग करें जो सामान्य HTTP शीर्षलेखों के अनुरूप है। बैकएंड के साथ बातचीत करते समय HTTP / 1.1 प्रोटोकॉल का उपयोग करना, दृश्यपटल इन छद्म शीर्षकों का अनुवाद करता है इसी तरह के HTTP / 1.1 HTTP हेडर में। समस्या यह है कि बैकएंड ट्रांसमिशन के विश्लेषण के बारे में निर्णय लेता है फ़्रंटएंड द्वारा निर्धारित HTTP शीर्षलेखों के आधार पर, मूल अनुरोध के मापदंडों को जाने बिना।
छद्म शीर्षकों के रूप में भी, मान "सामग्री-लंबाई" और "स्थानांतरण-एन्कोडिंग" उन्हें स्ट्रीम किया जा सकता है, हालांकि HTTP / 2 में उनका उपयोग नहीं किया जाता है, क्योंकि सभी डेटा का आकार एक अलग क्षेत्र में निर्धारित किया जाता है। हालाँकि, HTTP / 2 अनुरोध को HTTP / 1.1 में परिवर्तित करते समय, ये हेडर गुजरते हैं और बैकएंड को भ्रमित कर सकते हैं।
हमले के दो मुख्य विकल्प हैं: H2.TE और H2.CL, जिसमें बैकएंड को गलत ट्रांसफर एन्कोडिंग या सामग्री लंबाई मान द्वारा मूर्ख बनाया गया है जो HTTP / 2 प्रोटोकॉल के माध्यम से फ्रंटएंड द्वारा प्राप्त अनुरोध निकाय के वास्तविक आकार के अनुरूप नहीं है।
H2.CL हमले के उदाहरण के रूप में, छद्म हेडर में गलत आकार निर्दिष्ट किया गया है अनुरोध सबमिट करते समय सामग्री की लंबाई HTTP / 2 से नेटफ्लिक्स. यह अनुरोध हेडर जोड़ने की ओर ले जाता है HTTP सामग्री-लंबाई HTTP / 1.1 के माध्यम से बैकएंड तक पहुँचने पर समान, लेकिन आकार के बाद से कंटेंट की लम्बाई वास्तविक से कम है, कतार में डेटा का एक हिस्सा अगले अनुरोध की शुरुआत के रूप में संसाधित किया जाता है।
अटैक टूल्स को पहले ही बर्प के टूलकिट में जोड़ा जा चुका है और टर्बो इंट्रूडर एक्सटेंशन के रूप में उपलब्ध हैं। वेब प्रॉक्सी, लोड बैलेंसर्स, वेब एक्सेलेरेटर, कंटेंट डिलीवरी सिस्टम और अन्य कॉन्फ़िगरेशन जहां अनुरोध फ्रंटएंड-बैकएंड स्कीम में रीडायरेक्ट किए जाते हैं, समस्या के लिए अतिसंवेदनशील होते हैं।
Fuente: https://portswigger.net