मेरी हताशा हर समय अधिक है क्योंकि यह फिर से हुआ। यदि आपने मेरा पिछला विश्लेषण CVE-2022–29622: (In) भेद्यता विश्लेषण शीर्षक से पढ़ा है , तो आपको संदेह हो सकता है कि मैं किस बारे में बात कर रहा हूँ। कहानी वही, शिकार अलग। हालांकि, इस मामले में तारीखें महत्वपूर्ण हैं। मेरा पिछला अभेद्यता विश्लेषण 2022 से है, आज मैं 2018 से एक और मुद्दे का विश्लेषण करने जा रहा हूँ।

आप पूछ सकते हैं: "आपको 2018 से कुछ क्यों करना है?" बहुत बढ़िया सवाल! क्योंकि मैंने अभी हाल ही में डिपेंडेंसी ट्रैक को सोनाटाइप के ओएसएस इंडेक्स से भेद्यता जानकारी खींचने के लिए सक्षम किया है।

आज जब मैं एससीए के माध्यम से यह देखने के लिए स्किम कर रहा था कि क्या हमारे पास कोई कमजोर घटक हैं, और यदि हमने किया है, तो उपचारात्मक कार्य को प्राथमिकता दें। मुझे कुछ बहुत ही आश्चर्यजनक लगा। Koa.JS में गंभीर भेद्यता है?! मेरे सामान्य "#FFS के बाद, मेरे पूरे सप्ताह को पुनर्व्यवस्थित करने की आवश्यकता है।", मैं ऐसा था: "गहरी साँस लें और देखें कि यह किस बारे में है। आपको याद है कि पिछली बार क्या हुआ था…”

और इसलिए मैंने किया। सबसे पहले, शीर्षक यह स्पष्ट करता है कि "समस्या" 2018 में पाई गई थी। अब, मुझे उस लाइब्रेरी में भेद्यता क्यों होगी जो अभी भी बनी हुई है और मैं नवीनतम संस्करण में अपग्रेड करता रहता हूं? इस बिंदु पर मेरे दिमाग का खोजी हिस्सा सक्रिय हो गया।

हम इस बिंदु पर क्या जानते/देखते हैं?

1. कथित तौर पर कोआ में 2018 में गंभीर गंभीरता के साथ भेद्यता थी
2. सोनाटाइप ओएसएस इंडेक्स और डिपेंडेंसी ट्रैक के अनुसार कोआ के नवीनतम संस्करण को चलाने के दौरान यह समस्या मुझे 2022 में प्रभावित करती है

• Koa.JS लाइब्रेरी के कौन से संस्करण "भेद्यता" से प्रभावित थे
• यदि नवीनतम Koa.JS में "भेद्यता" मौजूद है

मुद्दे का विश्लेषण

आइए देखें कि "भेद्यता" क्या है / थी। मुझे यहां गिटहब से संबंधित मुद्दे #1250 को जल्दी से लिंक करने दें । मैं नीचे दिए गए उदाहरण (PoC?) को कॉपी-पेस्ट करूँगा ताकि हम इसका विश्लेषण कर सकें।

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

"एक वेब एप्लिकेशन या वेब सेवा के एक डेवलपर के रूप में, यदि आप मेरी वेबसाइट पर जाते हैं, तो मैं आपके ब्राउज़र को जहाँ चाहूँ वहाँ पुनर्निर्देशित कर सकता हूँ।"

उपरोक्त कोड का यही अर्थ है। उपरोक्त PoC में किसी दुर्भावनापूर्ण अभिनेता द्वारा किसी भी चीज़ का शोषण करने के लिए कोई अटैक वेक्टर प्रस्तुत नहीं किया गया है।

यदि आप इस गैर-भेद्यता के लिए उचित "पीओसी" प्रदान करना चाहते हैं (हाँ, मैंने अभी कहा), तो यह इस तरह दिखेगा:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

एक XSS भेद्यता के बारे में बात करते हुए, यदि मैंने vectorपैरामीटर के मान के रूप में जो कुछ भी दर्ज किया है वह HTML संदर्भ में असुरक्षित रूप से प्रदर्शित होता है, तो मैंने जो एप्लिकेशन लागू किया है वह क्रॉस साइट स्क्रिप्टिंग के लिए असुरक्षित होगा। (इस पर और बाद में)

सोनाटाइप ने इसे कैसे प्रस्तुत किया और इसका थोड़ा और विश्लेषण किया:

"क्रॉस-साइट स्क्रिप्टिंग के लिए खुला पुनर्निर्देशन"? सबसे पहले, कोई खुला पुनर्निर्देशन नहीं था। यह केवल तभी खुलता है जब आप इसे खोलते हैं और दो पीओसी (मूल और मेरा) के बीच का अंतर स्पष्ट रूप से दिखाता है। पहले में, कोई अटैक वेक्टर नहीं था, इस प्रकार कोई ओपन रीडायरेक्ट नहीं था। मेरे PoC में एक अटैक वेक्टर था, कोई फ़िल्टरिंग नहीं थी, इस प्रकार एक खुला रीडायरेक्ट था। लेकिन, जैसा कि आप देख सकते हैं, एक खुला पुनर्निर्देशन था या नहीं, यह मुझ पर निर्भर था, डेवलपर और Koa.JS पर नहीं। इससे भी बेहतर, पुनर्निर्देशन था या नहीं यह भी मुझ पर निर्भर था। क्या मैंने उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को असुरक्षित तरीके से रीडायरेक्ट URL के रूप में / में शामिल किया था, यह भी मेरे ऊपर था। हम किस Koa.JS भेद्यता के बारे में बात कर रहे हैं? तकनीकी रूप से, कोई भेद्यता नहीं थी और फिर भी किसी ने इसे गंभीर गंभीरता प्रदान की। बिल्कुल पेशेवर नहीं।

वैसे भी, उचित PoC द्वारा लागू "भेद्यता" का "शोषण" करें। कृपया ध्यान दें कि मुझे सर्विस पोर्ट को 3000 से 4444 में बदलना पड़ा क्योंकि मेरे पास पोर्ट 3000 पर पहले से ही कुछ सुन रहा था।

हम देख सकते हैं कि Locationप्रतिक्रिया शीर्षलेख का मान है javascript:alert(1)। फिर, ब्राउज़र रीडायरेक्ट करता है ...

हुह, मैं सुरक्षित हूँ! कोई अलर्ट बॉक्स पॉप अप नहीं हो रहा था। हां, मैं क्वेरी पैरामीटर https://google.comके मान के रूप में प्रवेश कर सकता हूं और Google पर पुनर्निर्देशित हो सकता हूं, इसलिए मेरा एप्लिकेशन (PoC) रीडायरेक्ट को खोलने के लिए असुरक्षित है, लेकिन Koa के कारण नहीं, बल्कि इसलिए कि मैंने अनफ़िल्टर्ड उपयोगकर्ता डेटा को पास कर दिया । ऐसा कुछ नहीं है जिसके बारे में मैं चिंतित हूं, मैं ऐसा कभी नहीं करूंगा।vectorctx.redirect

गिटहब पर टिप्पणी के मुद्दे से ध्यान देने वाली एक महत्वपूर्ण बात निम्नलिखित है:

समस्या इस तथ्य से उपजी है कि कोआ रीडायरेक्ट प्रतिक्रिया के शरीर में एक HTML हाइपरलिंक प्रिंट करता है और जो क्रॉस-साइट स्क्रिप्टिंग हमले को ट्रिगर कर सकता है।

आह, यह थोड़ा और समझ में आता है! देखते हैं कि क्या अब भी ऐसा ही है।

नहीं, अब ऐसा नहीं है। कोई प्रतिक्रिया निकाय नहीं है। मुझे लगता है कि मैं यह निष्कर्ष निकाल सकता हूं कि यह "भेद्यता" मुझे प्रभावित नहीं करती है। मैं बस जा सकता हूं और इसे डिपेंडेंसी ट्रैक में झूठी सकारात्मक के रूप में चिह्नित कर सकता हूं।

प्रसंग विश्लेषण

मैं सभी सुरक्षा पेशेवरों द्वारा अपनाए जाने वाले "संदर्भ विश्लेषण" का प्रस्ताव करता हूं और "मुद्दों" की रिपोर्ट करने से पहले प्रदर्शन करता हूं। इसे एक और उदाहरण बनने दें और आपको दिखाएं कि यह कैसे किया जाता है। (मैं अभी भी आपको CVE-2022–29622 पढ़ने की सलाह देता हूं: (In) भेद्यता विश्लेषण हालांकि यह संदर्भ के महत्व को बहुत बेहतर बताता है।)

1. Koa.JS आउट-ऑफ-द-बॉक्स आपको कहीं भी पुनर्निर्देशित नहीं करता है। इसलिए, सोनाटाइप ओएसएस इंडेक्स द्वारा बताए गए अनुसार "ओपन रीडायरेक्ट" नहीं था और न ही था।
2. GitHub पर प्रदान किए गए "PoC" के आधार पर, एक डेवलपर के लिए कुछ बेवकूफी करने का अवसर था जो XSS को जन्म दे सकता था। लेकिन, ऊपर #1 देखें। Koa.JS ने अपने आप कोई रीडायरेक्ट नहीं किया। नीचे #2 देखें।
3. रिपोर्ट की गई "भेद्यता" मौजूद होने के लिए एक डेवलपर ने अपने आवेदन को असुरक्षित तरीके से लागू किया होगा। इसका मतलब यह है कि Koa.JS भले ही बेहतर कर सकता था, आप इसे कमजोर नहीं कह सकते थे। यह प्रासंगिक रूप से अनुचित है। विचाराधीन भेद्यता केवल असुरक्षित रूप से कार्यान्वित वेब एप्लिकेशन में मौजूद हो सकती है ।

मैं आपको एक उदाहरण देता हूं कि कैसे इस तरह की स्थितियों को सबसे अच्छे तरीके से हैंडल किया जाता है। इस मुद्दे को देखें जो मैंने स्वैगर पार्सर को सबमिट किया था और इसे कैसे संप्रेषित किया गया था। आइए समस्या रिपोर्ट का विश्लेषण करें:

1. शीर्षक "असुरक्षित रिज़ॉल्वर व्यवहार" कहता है। मैं शीर्षक में LFI (स्थानीय फ़ाइल समावेशन) के बारे में बात नहीं कर रहा हूँ। ऐसा इसलिए है क्योंकि अगर मैं चीजों को गड़बड़ करता हूं तो स्थानीय फाइल समावेशन की संभावना है , यह वास्तव में एक डेवलपर के रूप में मेरे ऊपर है कि मैं किसके साथ काम कर रहा हूं और मैं इसके साथ कैसे काम कर रहा हूं। डिफ़ॉल्ट व्यवहार असुरक्षित था (शायद अभी भी है)। लेकिन पुस्तकालय अपने दम पर, मेरी भागीदारी के बिना कुछ नहीं करेगा।
2. फिर, मैं स्पष्ट रूप से बताता हूं कि मैं पुस्तकालय के किस संस्करण के बारे में बात कर रहा हूं। मैं उन शर्तों को सूचीबद्ध करके संदर्भ को और भी स्पष्ट करता हूं जिनके तहत लाइब्रेरी का असुरक्षित डिफ़ॉल्ट व्यवहार किसी एप्लिकेशन को प्रभावित करेगा। इससे यह स्पष्ट हो जाता है कि पुस्तकालय स्वयं असुरक्षित नहीं है, लेकिन इसमें एक असुरक्षित व्यवहार है जिसे डेवलपर्स की सहायता के लिए सुधारा जा सकता है।
3. इसलिए अब जब संदर्भ सेट हो गया है, तो मैं एक कार्यशील PoC प्रदान करता हूं, एक कमजोर कोड स्निपेट (जिसे मैंने PoC के रूप में लिखा है, यह स्वैगर पार्सर का हिस्सा नहीं है!) और एक कमजोर ऐप/सेवा के शोषण का वास्तविक परिणाम जो इसका उपयोग करता है। पुस्तकालय असुरक्षित रूप से।
4. मैंने कुछ जांच की और पाया कि एक डेवलपर के रूप में मैं वास्तव में पुस्तकालय को इस तरह से कॉन्फ़िगर कर सकता हूं जो समस्या को कम करता है। (एक हद तक) मैंने इसे देवों के साथ साझा किया। अगर और कुछ नहीं, तो कम से कम वे जागरूकता बढ़ाने के लिए दस्तावेज़ीकरण को अपडेट कर सकते हैं।
5. मैंने अतिरिक्त संदर्भ, विश्लेषण और चीजों को कैसे बेहतर बनाया जा सकता है इसका एक उदाहरण प्रदान किया।

निष्कर्ष

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

मुझे संदेह है कि निर्भरता ट्रैक एफओएमओ से पीड़ित है, इस प्रकार, संस्करण संख्या उपलब्ध नहीं होने पर यह पूरी तरह से घटक नाम मिलान के आधार पर मुद्दों की रिपोर्ट करने को तैयार है। मैं एक हद तक समझता हूं कि वे एक महत्वपूर्ण भेद्यता को खोने का जोखिम नहीं उठाएंगे। इस व्यवहार (गलत सकारात्मक) के साथ समस्या यह है कि यह सॉफ़्टवेयर संरचना विश्लेषण को अपनाने को प्रोत्साहित नहीं करता है। यह स्थिर कोड विश्लेषण की झूठी सकारात्मकता की तरह डेवलपर्स को डरा देगा। प्रतिकूल।

संदर्भ! खूनी संदर्भ, लोग! मैंने प्रस्ताव दिया:

1. "संदर्भ विश्लेषण" सभी सुरक्षा पेशेवरों द्वारा अपनाया जाना चाहिए और "मुद्दों" की रिपोर्ट करने से पहले किया जाना चाहिए
2. भेद करना "असुरक्षित व्यवहार" "भेद्यता" से
3. सॉफ़्टवेयर लाइब्रेरी और एप्लिकेशन/सेवा के बीच अंतर को समझना