यह रिपॉज़िटरी एक बाहरी पेनिट्रेशन परीक्षक के दृष्टिकोण से CVE-2026-34835 का ब्लैक-बॉक्स सुरक्षा विश्लेषण प्रदान करती है।

इसका उद्देश्य भेद्यता को रिवर्स इंजीनियर करना नहीं है, बल्कि यह दस्तावेजित करना है कि एक सुरक्षा मूल्यांकक एक अधिकृत मूल्यांकन के दौरान इसके प्रभाव की पहचान, सत्यापन और मूल्यांकन कैसे कर सकता है।

CVE-2026-34835 (Rack Host Header Bypass) का ब्लैक-बॉक्स विश्लेषण

CVE-2026-34835 पर एक डायनेमिक एप्लिकेशन सिक्योरिटी टेस्टिंग (DAST) दृष्टिकोण, जो एक मध्यम-गंभीरता वैधता बाईपास भेद्यता है।

यह रिपोर्ट मूल्यांकन करती है कि यह दोष एक बाहरी, ब्लैक-बॉक्स पेनिट्रेशन टेस्टिंग परिप्रेक्ष्य से कैसे प्रकट होता है, जो केवल देखने योग्य व्यवहार और एप्लिकेशन प्रतिक्रिया विसंगतियों पर केंद्रित है।

📌 भेद्यता अवलोकन

• CVE ID: CVE-2026-34835
• घटक: Rack::Request हैंडलिंग लॉजिक
• भेद्यता प्रकार:
  • CWE-20 (अनुचित इनपुट सत्यापन)
  • CWE-1286 (इनपुट की वाक्यविन्यास शुद्धता का अनुचित सत्यापन)
• CVSS स्कोर: 4.8 (मध्यम)
• प्रभावित संस्करण: 3.0.0.beta1 से < 3.1.21, और 3.2.0 से < 3.2.6
• अनुशंसित स्थिर संस्करण: 3.1.21 और 3.2.6

🔍 भेद्यता सारांश

सार्वजनिक सुरक्षा सलाह के अनुसार, प्रभावित Rack संस्करण कुछ दुर्भावनापूर्ण Host हेडर मानों को गलत तरीके से संसाधित कर सकते हैं, जिससे अप्रत्याशित एप्लिकेशन व्यवहार होता है। यह विश्लेषण स्रोत कोड समीक्षा पर निर्भर नहीं करता है और केवल सार्वजनिक रूप से उपलब्ध सलाह और देखने योग्य एप्लिकेशन व्यवहार पर आधारित है।

Host हेडर विश्वास निर्णयों पर निर्भर करने वाले एप्लिकेशन अप्रत्याशित व्यवहार कर सकते हैं यदि दुर्भावनापूर्ण मान स्वीकार किए जाते हैं। जब डाउनस्ट्रीम एप्लिकेशन नियंत्रण या फ्रंट-एंड रूटिंग परतें आंशिक स्ट्रिंग सत्यापन विधियों—जैसे उपसर्ग या प्रत्यय की जाँच—पर निर्भर करती हैं, तो यह ढीला सत्यापन तंत्र दुर्भावनापूर्ण इनपुट को इच्छित हैंडलिंग लॉजिक को बायपास करने की अनुमति दे सकता है।

🗺️ ब्लैक-बॉक्स मूल्यांकन पद्धति

निम्नलिखित कार्यप्रवाह बाहरी दृष्टिकोण से व्यवहार का विश्लेषण करने के लिए उपयोग किए जाने वाले ब्लैक-बॉक्स प्रतिकृति पाइपलाइन को दर्शाता है:

निष्क्रिय फिंगरप्रिंटिंग (जब संभव हो तब अंतर्निहित बुनियादी ढांचे की पहचान करने का प्रयास)
      │
      ▼
Host हेडर में हेरफेर (इंटरसेप्टिंग प्रॉक्सी के माध्यम से दुर्भावनापूर्ण विविधताएँ इंजेक्ट करें)
      │
      ▼
प्रतिक्रिया अंतर का निरीक्षण (स्थिति कोड और हेडर व्यवहार का विश्लेषण करें)
      │
      ▼
एप्लिकेशन व्यवहार सत्यापित करें (निर्धारित करें कि क्या दुर्भावनापूर्ण मान स्वीकार किए जाते हैं)
      │
      ▼
संभावित सुरक्षा प्रभाव का मूल्यांकन (व्यावसायिक तर्क निहितार्थों का मानचित्रण)

🎯 ब्लैक-बॉक्स परीक्षण और उदाहरणात्मक परीक्षण उदाहरण

ब्लैक-बॉक्स परीक्षण के दृष्टिकोण से, एक ऑडिटर एक इंटरसेप्टिंग प्रॉक्सी (जैसे, Burp Suite Repeater) का उपयोग करके Host हेडर में हेरफेर करके और यह देखकर आकलन कर सकता है कि क्या लक्ष्य संवेदनशील प्रतीत होता है कि सर्वर अनुरोध को HTTP 400 Bad Request के साथ छोड़ने के बजाय प्रसंस्करण जारी रखता है।

काल्पनिक उदाहरण: उपसर्ग सत्यापन विसंगति

एक काल्पनिक परिदृश्य पर विचार करें जहां एक बाहरी परिधि नियम एक विश्वसनीय स्ट्रिंग प्रारूप के आधार पर ट्रैफ़िक को प्रतिबंधित या विशिष्ट पहुँच प्रदान करता है:

• अनुमानित तर्क: सिस्टम उन अनुरोधों को संसाधित करता है जो एक विशिष्ट उपसर्ग स्थिति (जैसे, trusted-banking.com) से मेल खाते हैं।

मूल्यांकन के दौरान, एक ऑडिटर हेडर की समग्र संरचना को बदलते हुए विश्वसनीय स्ट्रिंग को हेडर की शुरुआत में रखने के लिए प्राधिकरण नियंत्रण वर्णों (जैसे @) का लाभ उठा सकता है:

GET / HTTP/1.1
Host: [email protected]
User-Agent: Mozilla/5.0
Connection: close

• संवेदनशील नियोजनों पर अपेक्षित व्यवहार: सर्वर HTTP 400 Bad Request के साथ तुरंत अस्वीकार करने के बजाय दुर्भावनापूर्ण अनुरोध को संसाधित करना जारी रख सकता है।
• संभावित सुरक्षा निहितार्थ: क्योंकि दुर्भावनापूर्ण मान स्वीकार किया जाता है, कोई भी डाउनस्ट्रीम रूटिंग या एप्लिकेशन फ़िल्टर जो उस विशिष्ट उपसर्ग की जाँच कर रहा है, इनपुट का गलत मूल्यांकन कर सकता है, जिससे संभावित रूप से इनपुट सत्यापन बाईपास हो सकता है।

🔍 संभावित भेद्यता के संकेतक

गतिशील विश्लेषण के दौरान, दुर्भावनापूर्ण Host मान इनपुट करते समय निम्नलिखित संभावित व्यवहारों की तलाश करें:

• रीडायरेक्ट में Host हेडर परिलक्षित: जाँचें कि क्या स्थान हेडर इंजेक्ट किए गए स्ट्रिंग से मेल खाते हैं।
• Host से उत्पन्न निरपेक्ष URL: प्रतिक्रिया निकाय में एम्बेडेड लिंक या संपत्ति परिभाषाओं के अंदर इंजेक्ट किए गए घटकों की तलाश करें।
• दुर्भावनापूर्ण Host के लिए अलग प्रतिक्रियाएँ: मानक और इंजेक्ट किए गए हेडर के बीच स्थिति या त्रुटि प्रबंधन में परिवर्तन की निगरानी करें।
• कैश विसंगतियाँ: देखें कि क्या दुर्भावनापूर्ण प्रतिक्रियाएँ अपस्ट्रीम परतों द्वारा कैश की जाती हैं।
• अप्रत्याशित वर्चुअल होस्ट रूटिंग: जाँचें कि क्या एप्लिकेशन हेरफेर किए गए हेडर को संसाधित करते समय अप्रत्याशित एंडपॉइंट प्रस्तुत करता है।

⚠️ संभावित सुरक्षा प्रभाव

यद्यपि यह सत्यापन विसंगति स्वयं प्रत्यक्ष कमांड निष्पादन क्षमता प्रदान नहीं करती है, यह द्वितीयक उच्च-प्रभाव हमलों के लिए एक महत्वपूर्ण उत्प्रेरक के रूप में कार्य करती है:

1. Host Header Poisoning: सिस्टम को लिंक या एप्लिकेशन संपत्ति पथ उत्पन्न करने के लिए मजबूर करना जो हमलावर के इनपुट को दर्शाते हैं।
2. Web Cache Poisoning: अपस्ट्रीम कैशिंग परतों (जैसे CDNs या रिवर्स प्रॉक्सी) को असामान्य प्रतिक्रिया को संग्रहीत करने और बाद के उपयोगकर्ताओं को वितरित करने के लिए धोखा देना।
3. अनपेक्षित रूटिंग व्यवहार: अनपेक्षित रूटिंग व्यवहार में योगदान देना जब नेटवर्क बुनियादी ढाँचा विन्यास कच्चे Host मानों पर भारी रूप से निर्भर करता है।

📝 पेनिट्रेशन परीक्षक नोट

• संभावित फिंगरप्रिंटिंग अवसर: जब देखने योग्य संकेतक मौजूद हों (जैसे X-Rack-Cache हेडर, कस्टम कुकी संरचनाएँ, या विशिष्ट स्टैक ट्रेस प्रारूप), तो निष्क्रिय फिंगरप्रिंटिंग Rack-आधारित नियोजनों की पहचान करने में मदद कर सकती है।
• त्रुटि प्रबंधन जाँचें: निगरानी करें कि क्या इंजेक्शन विविधताएँ HTTP 400 Bad Request लौटाती हैं या प्रसंस्करण जारी रखती हैं।
• पैरामीटर विविधताओं का परीक्षण: Host हेडर को कई नियंत्रण वर्णों (@, /, ?, #) के साथ फज़ करें ताकि यह देखा जा सके कि बुनियादी ढाँचा सीमाओं को कैसे संभालता है।
• रीडायरेक्ट व्यवहार का निरीक्षण: विश्लेषण करें कि क्या प्रतिक्रिया निकाय में स्थान हेडर या निरपेक्ष पथ दुर्भावनापूर्ण स्ट्रिंग को दर्शाते हैं।
• कैश व्यवहार की समीक्षा करें: X-Cache हेडर की जाँच करें ताकि मूल्यांकन किया जा सके कि क्या असामान्य होस्ट स्ट्रिंग अपस्ट्रीम प्रॉक्सी द्वारा कैश की गई हैं।

📋 ब्लैक-बॉक्स परीक्षण चेकलिस्ट

• निष्क्रिय फ्रेमवर्क फिंगरप्रिंटिंग का प्रयास करें।
• एक आधार रेखा अनुरोध कैप्चर करें।
• दुर्भावनापूर्ण Host हेडर इंजेक्ट करें।
• आधार रेखा बनाम हेरफेर की गई प्रतिक्रियाओं की तुलना करें।
• रीडायरेक्ट और निरपेक्ष URL उत्पादन का निरीक्षण करें।
• कैश-संबंधित हेडर का निरीक्षण करें।
• व्यवहारिक अंतरों का दस्तावेजीकरण करें।
• संभावित सुरक्षा प्रभाव का आकलन करें।

📅 भेद्यता समयरेखा

• सलाह: सार्वजनिक सलाह जारी की गई जिसमें GHSA-g2pf-xv49-m2h5 के तहत दुर्भावनापूर्ण Host मानों के अपर्याप्त सत्यापन का वर्णन किया गया है।
• पैच: आधिकारिक उपचार संस्करण सार्वजनिक रिपॉज़िटरी में तैनात किए गए।
• प्रभावित संस्करण: 3.0.0.beta1 से < 3.1.21, और 3.2.0 से < 3.2.6 का उपयोग करने वाले सभी उत्पादन उदाहरण।
• अनुशंसित स्थिर संस्करण: बुनियादी ढाँचा स्थिर रिलीज़ 3.1.21 या 3.2.6 में अपग्रेड किया गया।

💡 सीखे गए सबक

• गहराई में रक्षा: परिधि बुनियादी ढाँचा सत्यापन को कभी भी स्पष्ट एप्लिकेशन-लेयर सीमा सत्यापन को पूरी तरह से प्रतिस्थापित नहीं करना चाहिए।
• इनपुट स्वच्छता: Host हेडर को अविश्वसनीय उपयोगकर्ता इनपुट के रूप में माना जाना चाहिए और महत्वपूर्ण तर्क रूटिंग के लिए कभी भी आँख बंद करके भरोसा नहीं करना चाहिए।
• सत्यापन कठोरता: सटीक होस्टनाम तुलना (सख्त श्वेत-सूची) आंशिक सत्यापन सहायकों जैसे उपसर्ग मिलान की तुलना में स्वाभाविक रूप से सुरक्षित है।
• सक्रिय पैच प्रबंधन: बुनियादी ढाँचा पैच तुरंत लागू किए जाने चाहिए क्योंकि मामूली प्रतीत होने वाले पार्सिंग बग उच्च-स्तरीय ब्लैक-बॉक्स सुरक्षा धारणाओं को अमान्य कर सकते हैं।

🛡️ उपचार और सुरक्षा

• निर्भरता पैचिंग: Ruby वातावरण में कोर rack gem निर्भरता को संस्करण 3.1.21, 3.2.6, या उच्चतर में अपग्रेड करें।
• सख्त मिलान नियम: उपसर्ग मूल्यांकन के बजाय एक स्पष्ट डोमेन सरणी कॉन्फ़िगरेशन के विरुद्ध सख्त सटीक मिलान लागू करें।
• अपस्ट्रीम गेटवे फ़िल्टरिंग: इनग्रेस कंट्रोलर, API गेटवे, या रिवर्स प्रॉक्सी (Nginx, Apache) को कॉन्फ़िगर करें कि वे किसी भी HTTP अनुरोध को स्पष्ट रूप से हटा दें जहाँ Host हेडर में वाक्यविन्यास उल्लंघन या URI सीमांकक हों, इससे पहले कि अनुरोध वेब एप्लिकेशन इंटरफ़ेस तक पहुँचे।

🚫 सीमाएँ

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

🏁 मुख्य निष्कर्ष

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

📚 संदर्भ

• NVD CVE रिकॉर्ड: [https://nvd.nist.gov/vuln/detail/cve-2026-34835]
• GitHub सुरक्षा सलाह: [https://github.com/advisories/GHSA-g2pf-xv49-m2h5]
• CWE-20 परिभाषा: [https://cwe.mitre.org/data/definitions/20.html]
• CWE-1286 परिभाषा: [https://cwe.mitre.org/data/definitions/1286.html]

अस्वीकरण: यह विश्लेषण विशेष रूप से शैक्षिक उद्देश्यों, पोर्टफोलियो प्रतिनिधित्व और अधिकृत सुरक्षा अनुसंधान के लिए प्रकाशित किया गया है।