अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना वेब सिस्टम जेथे फ्रंटएंड HTTP / 2 द्वारे कनेक्शन स्वीकारते आणि त्यांना HTTP / 1.1 h द्वारे बॅकएंडकडे पाठवते"HTTP रिक्वेस्ट स्मगलिंग" हल्ल्याच्या नवीन आवृत्तीचा खुलासा झाला आहे, हे फ्रंटएंड आणि बॅकएंड दरम्यान समान प्रवाहात प्रक्रिया केलेल्या इतर वापरकर्त्यांच्या विनंत्यांच्या सामग्रीमध्ये विशेषतः डिझाइन केलेल्या क्लायंट विनंत्या पाठवून अनुमती देते.
हल्ला दुर्भावनायुक्त जावास्क्रिप्ट कोड इंजेक्ट करण्यासाठी वापरला जाऊ शकतो कायदेशीर साइटसह सत्रात, प्रवेश प्रतिबंधित प्रणाली बायपास करा आणि प्रमाणीकरण मापदंड अडवा.
अभ्यासाचे लेखक Netflix, Verizon, Bitbucket, Netlify CDN आणि Atlassian प्रणालींवर हल्ला करण्याची शक्यता दाखवली, आणि भेद्यता ओळखण्यासाठी $ 56.000 बक्षीस कार्यक्रमांमध्ये प्राप्त केले. F5 नेटवर्क उत्पादनांमध्येही या समस्येची पुष्टी झाली आहे.
समस्या अपाचे http सर्व्हरवर mod_proxy अंशतः प्रभावित करते (CVE-2021-33193), आवृत्ती 2.4.49 मध्ये अपेक्षित निराकरणे (विकसकांना मे महिन्याच्या सुरुवातीला समस्येबद्दल सूचित केले गेले होते आणि त्याचे निराकरण करण्यासाठी 3 महिने देण्यात आले होते). Nginx मध्ये, "सामग्री-लांबी" आणि "हस्तांतरण-एन्कोडिंग" शीर्षलेख एकाच वेळी निर्दिष्ट करण्याची क्षमता मागील आवृत्तीत (1.21.1) अवरोधित केली गेली होती.
नवीन पद्धतीच्या ऑपरेशनचे सिद्धांत रहदारीमध्ये जुळणाऱ्या विनंत्यांची दोन वर्षांपूर्वी त्याच संशोधकाने शोधलेल्या असुरक्षिततेसारखे आहे, परंतु हे HTTP / 1.1 वर विनंत्या स्वीकारणाऱ्या इंटरफेसपुरते मर्यादित आहे.
क्लासिक "एचटीटीपी रिक्वेस्ट स्मगलिंग" अटॅक या वस्तुस्थितीवर आधारित होता की फ्रंटएंड्स आणि बॅकएंड्स एचटीटीपी "कंटेंट-लेंथ" हेडरच्या वापराचा वेगळा अर्थ लावतात (विनंतीमधील डेटाचा एकूण आकार निर्धारित करते) आणि "ट्रान्सफर-एन्कोडिंग: चंक्ड" ( तुम्हाला भागांमध्ये डेटा ट्रान्सफर करण्याची परवानगी देते) ...
उदाहरणार्थ, जर इंटरफेस फक्त "कंटेंट-लेंथ" ला सपोर्ट करतो पण "ट्रान्सफर-एन्कोडिंग: फ्रॅग्मेंटेड" कडे दुर्लक्ष करतो, तर हल्लेखोर विनंती पाठवू शकतो ज्यात "कंटेंट-लेंथ" आणि "ट्रान्सफर-एन्कोडिंग: फ्रॅग्मेंटेड" हेडर असतात, पण आकार 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 ते Netflix. या विनंतीमुळे हेडर जोडले जाते HTTP सामग्री-लांबी HTTP / 1.1 द्वारे बॅकएंडमध्ये प्रवेश करताना समान, परंतु आकारात असल्याने सामग्री-लांबी वास्तविक पेक्षा कमी आहे, रांगेतील डेटाचा एक भाग पुढील विनंतीची सुरुवात म्हणून प्रक्रिया केली जाते.
हल्ल्याची साधने बर्पच्या टूलकिटमध्ये आधीच जोडली गेली आहेत आणि टर्बो घुसखोर विस्तार म्हणून उपलब्ध आहेत. वेब प्रॉक्सी, लोड बॅलेन्सर, वेब एक्सीलरेटर, सामग्री वितरण प्रणाली आणि इतर कॉन्फिगरेशन जेथे फ्रंटएंड-बॅकएंड स्कीममध्ये विनंत्या पुनर्निर्देशित केल्या जातात त्या समस्येसाठी अतिसंवेदनशील असतात.
स्त्रोत: https://portswigger.net