Koa.js अभेद्यता विश्लेषण अद्यतन

Nov 26 2022

बहुत पहले नहीं, मैंने 2018 में Koa.js को प्रभावित करने वाली भेद्यता के बारे में लिखा था।

बहुत पहले नहीं, मैंने 2018 में Koa.js को प्रभावित करने वाली एक भेद्यता के बारे में लिखा था। मैं निराश था कि मुझे 2018 से एक समस्या से निपटना था, जबकि तारीख 2022 थी, और मैं Koa के नवीनतम संस्करण का उपयोग कर रहा था। 4 साल हो गए। लंबा समय हो गया है। निश्चित रूप से अब मुद्दा नहीं है !? और यह एक ही समय में था और नहीं था। इसका मतलब है कि मैं एक ही समय में गलत और सही था। तो, यहाँ पिछली पोस्ट का एक अपडेट है जो आपको बताता है कि कैसे:

मैंने गलत तरीके से सोनाटाइप और डिपेंडेंसी ट्रैक पर विशिष्ट मामलों में संस्करण जानकारी के साथ काम नहीं करने का आरोप लगाया
मैं भेद्यता के बारे में एक ही समय में सही और गलत हो सकता हूं

ओएसएस इंडेक्स में वर्जन की जानकारी है

यदि आपने मेरी पिछली पोस्ट पढ़ी है, तो आपको शायद याद होगा कि मैंने निष्कर्ष निकाला था कि इस मुद्दे ने मुझे प्रभावित नहीं किया। अच्छी खबर यह है कि मैं सही था। बुरी खबर यह है कि मैंने सोनाटाइप पर गलत तरीके से आरोप लगाया कि ओएसएस इंडेक्स द्वारा डिपेंडेंसी ट्रैक के साथ काम करने के लिए प्रदान किए गए डेटा में संस्करण संख्याएं नहीं हैं। यह पता चला है कि उनके पास जानकारी है। यह सिर्फ दिखाई नहीं दे रहा था जहाँ मुझे उम्मीद थी कि यह दिखाई देना चाहिए था। नीचे 22/11/2022 को लिया गया स्क्रीनशॉट देखें।

प्रभावित संस्करणों के बारे में जानकारी गायब है

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

Koa संस्करण और बुनियादी भेद्यता काउंटर द्वारा

तो मैं गलत था। सोनाटाइप के पास डेटाबेस में जानकारी है। समस्या तब प्रस्तुति परत के साथ है। यह बेहतर होगा यदि उनके प्रभावित संस्करण उस पृष्ठ पर सूचीबद्ध हों जहां वास्तव में भेद्यता पर चर्चा की गई है ताकि हम जरूरत पड़ने पर देख सकें और सत्यापित कर सकें।

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

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

क्रॉस साइट स्क्रिप्टिंग

Sonatype ने निम्न विचार प्रक्रिया के आधार पर XSS को Koa को जिम्मेदार ठहराया।

Koa वह इकाई है जो HTML प्रतिक्रिया के लिए URL लिख रही है, न कि Koa का उपयोग करने वाला डेवलपर

यह उम्मीद करना निश्चित रूप से उचित है कि डेवलपर आपूर्ति किए गए URL को मान्य करें, संभवतः एक अनुमति-सूची के विरुद्ध, एक खुले पुनर्निर्देशन को रोकने के लिए और Koa को नहीं क्योंकि Koa को पता नहीं होगा कि आप कौन से URL की अनुमति देना चाहते हैं या नहीं। हालाँकि, एक डेवलपर के रूप में, मुझे नहीं लगता कि मुझे एक URL के लिए XSS स्वच्छता करने के बारे में चिंता करनी चाहिए, मैं एक रीडायरेक्ट () विधि से गुजर रहा हूँ।

Koa इस संदर्भ में XSS के बारे में परवाह करता है क्योंकि उनके पास इसे रोकने के लिए पहले से ही कोड है, HTML इकाई URL को एन्कोडिंग करते समय इसे HTML पर लिखती है

मैं काफी हद तक सहमत हूं। मैं निम्नलिखित से सहमत नहीं हूँ, उदाहरण के लिए।

मुझे नहीं लगता कि मुझे उस यूआरएल के लिए एक्सएसएस स्वच्छता करने की चिंता करनी चाहिए जिसे मैं रीडायरेक्ट() विधि से गुजर रहा हूं

यदि आप (डेवलपर) द्वारा प्रदान की गई रीडायरेक्ट विधि के लिए एक मान्य, सुरक्षित URL पास करते हैं, तो आपको XSS (स्पष्ट रूप से) के बारे में चिंता करने की आवश्यकता नहीं है। यदि आप पूरी तरह से या आंशिक रूप से उपयोगकर्ता द्वारा प्रदान किया गया डेटा पास करते हैं, तो यह एक ऐसी चीज है जिसके बारे में आपको हमेशा चिंता करनी चाहिए, चाहे आप एक डेवलपर हों या सुरक्षा पेशेवर। फिर भी, Koa से डेवलपर की मदद करने की उम्मीद करना दूर की कौड़ी नहीं है।

मैं आपको एक उत्कृष्ट उदाहरण देता हूं जो मुझे यह समझने में मदद करता है कि मैं कहां से आ रहा हूं। नीचे दिए गए उदाहरण में, मैं प्रतिक्रिया निकाय में उपयोगकर्ता द्वारा प्रदान किए गए डेटा को वापस ब्राउज़र में पास करता हूं। मैं इसे बिना किसी सत्यापन, स्वच्छता या एन्कोडिंग के करता हूं।

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

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

इस बारे में सोचें कि प्रतिक्रिया निकाय में मैं ब्राउज़र को क्या और कैसे पास करता हूं
प्रतिक्रिया के लिए सामग्री-प्रकार शीर्षलेख के मान पर विचार करें (और शायद स्पष्ट रूप से नियंत्रित करने के लिए सबसे अच्छा!)
यह जान लें कि Koa, डिफ़ॉल्ट रूप से, सामग्री-प्रकार हेडर के मान को पास किए गए मान के आधार पर स्वचालित रूप से समायोजित करता है ctx.body। (उदाहरण के लिए पास होने का प्रयास करें aaa, और देखें कि यह कैसे बदलता है)

उपरोक्त ctx.body"XSS" उदाहरण को ध्यान में रखते हुए, ऐसा लगता है कि हम Koa को उपयोग करते समय किसी आपदा को रोकने के लिए विशिष्ट उपायों को लागू करने के लिए दोषी ठहरा रहे थे ctx.redirect()। सोनाटाइप को फिर से उद्धृत करना:

Koa इस संदर्भ में XSS की परवाह करता है क्योंकि उनके पास पहले से ही कोड है।

क्या इसका मतलब यह है कि अगर Koa ने इस संदर्भ में XSS के बारे में परवाह नहीं की, इसी तरह जब वे इसके बारे में परवाह नहीं करते (और नहीं करना चाहिए) ctx.body, तो कोई भी इसे XSS भेद्यता के रूप में चिह्नित नहीं करेगा? यह काफी मजेदार है। मैंने यहां और यहां प्रलेखित दुर्जेय के बारे में अपने पहले के विश्लेषण के साथ कुछ समानताएं देखीं ।

अब तक मैंने जो कुछ भी कहा है, उसके बाद एक XSS होता है ... और उसी समय नहीं। वो कैसे संभव है? सीधा! यह वहां है, लेकिन आप इसका तब तक दोहन नहीं कर सकते जब तक कि:

पीड़ित एक पुराने वेब ब्राउज़र का उपयोग करता है, और
ctx.redirect()Koa's , AND का उपयोग करके डेवलपर द्वारा एक खुला रीडायरेक्ट लागू किया गया है
डेवलपर उपयोगकर्ता द्वारा प्रदान किए गए सभी डेटा पर पूरी तरह से भरोसा करता है और इसे शब्दशः पास करता हैctx.redirect()

सोनाटाइप रिपोर्ट पेज ने कहा कि जैसा कि आप आज के स्क्रीनशॉट से देख सकते हैं, "क्रॉस-साइट स्क्रिप्टिंग के लिए रीडायरेक्ट खोलें"। मेरी पिछली पोस्ट ने "ओपन रीडायरेक्ट" भाग पर सवाल उठाया था:

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

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

जैसा कि पहले उल्लेख किया गया है, कोआ के व्यवहार का सफलतापूर्वक दोहन करने के लिए एक खुले पुनर्निर्देशन की आवश्यकता होती है। लेकिन:

Koa खुले पुनर्निर्देशन को रोकने के लिए ज़िम्मेदार नहीं है (जैसा कि पहले निष्कर्ष निकाला गया था)
ctx.redirect()कोआ डेवलपर के कहने के बिना निष्पादित नहीं करेगा
कोआ डेवलपर्स को रीडायरेक्ट का उपयोग करने के लिए बाध्य नहीं करता है

तो, सुरक्षा की एक और परत है: उपयोग के मामले। इस बात की कितनी संभावना है कि कोई डेवलपर इस बात पर कुछ नियंत्रण नहीं चाहेगा कि ब्राउज़र को कहां रीडायरेक्ट किया जाता है? बहुत संभावना नहीं। इसका मतलब यह है कि, सबसे अधिक संभावना है, डेवलपर्स उपयोगकर्ता-नियंत्रित डेटा को ctx.redirect()स्ट्रिंग के दूसरे टुकड़े में संलग्न करने के लिए पास करेंगे। इसलिए, नीचे दिखाए गए उदाहरणों के समान कुछ होने की सबसे अधिक संभावना है:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

भेद्यता स्कोरिंग

बग के उपयोग योग्य होने के लिए तीन (3) शर्तों को पूरा करना होगा, जैसा कि पिछले खंड के अंत में चर्चा की गई है।

ब्राउज़र के किस संस्करण का उपयोग किया जाता है, यह अंतिम उपयोगकर्ता पर निर्भर करता है
रीडायरेक्ट विधि का उपयोग और इसका उपयोग कैसे किया जाता है, यह डेवलपर पर निर्भर है

इस बात पर भी जोर देने की आवश्यकता है कि असुरक्षित तरीके से पुनर्निर्देशन पद्धति का उपयोग आक्रमण वेक्टर है। सफल शोषण के लिए एक अटैक वेक्टर की आवश्यकता होती है। कोआ हमला वेक्टर प्रदान नहीं करता है; डेवलपर करता है।

आइए इसे NIST द्वारा प्रदान की गई "सॉफ़्टवेयर भेद्यता" की परिभाषा से संबद्ध करें:

https://csrc.nist.gov/glossary/term/software_vulnerability

मैं जिस हिस्से पर प्रकाश डालना चाहूंगा वह है "शोषण किया जा सकता है"। Koa को एक सॉफ्टवेयर लाइब्रेरी के रूप में लें। क्या आप पहले आवश्यक अटैक वेक्टर बनाए बिना इसका फायदा उठा सकते हैं? नहीं, तो, Koa के दृष्टिकोण से, एक सॉफ्टवेयर लाइब्रेरी, कोई अटैक वेक्टर प्रस्तुत नहीं किया गया है; इसके बिना शोषण असंभव है। यदि हम परिभाषा की सख्ती से व्याख्या करते हैं (जो मैं करता हूं), तो हम कोआ के व्यवहार को भेद्यता नहीं कह सकते।
आइए हमले के वेक्टर के बिना सीवीएसएस स्कोर की गणना करने का प्रयास करें:

अटैक वेक्टर के बिना CVSS स्कोर की गणना करना

अगर कोई अटैक वेक्टर नहीं है तो कोई स्कोर नहीं है। मैं कहूंगा कि यह NIST द्वारा प्रदान की गई सॉफ़्टवेयर भेद्यता की परिभाषा के अनुरूप है।
आइए प्रयोग करें और एक काल्पनिक परिदृश्य बनाएं जहां एक आक्रमण वेक्टर मौजूद हो।

काल्पनिक हमला वेक्टर

काल्पनिक हमले वेक्टर के अलावा, यहां अभी भी कई समस्याएं हैं। हमले की जटिलता को उच्च पर सेट किया गया था क्योंकि सफल शोषण के लिए पुराने ब्राउज़र की आवश्यकता होती है। एक हमलावर को पीड़ितों को पुराने ब्राउज़र को डाउनलोड और इंस्टॉल करने के लिए राजी करना होगा।
उस अर्थ में, उपयोगकर्ता सहभागिता आवश्यक है, भले ही उपयोगकर्ता सहभागिता आधार मेट्रिक्स वास्तव में इसके बारे में नहीं हैं। इस परिदृश्य में, XSS का उपयोग करने के लिए उपयोगकर्ता सहभागिता की आवश्यकता होती है या नहीं, यह इस बात पर निर्भर करता है कि वेब एप्लिकेशन कैसे रीडायरेक्ट का उपयोग करता है और Koa पर नहीं। यह भी ध्यान देने योग्य है कि इंजेक्ट किया गया जावास्क्रिप्ट अपने आप निष्पादित नहीं होगा क्योंकि इसके लिए पहली बार में उपयोगकर्ता सहभागिता की आवश्यकता होती है: HTML प्रतिक्रिया में लिंक पर क्लिक करना।

तो हम इस पर भेद्यता स्कोर लागू करने के लिए क्या कर सकते हैं? हमें कुछ चुनना चाहिए। इच्छाधारी सोच, सबसे बुरा मानकर, जो भी आप पसंद करते हैं। एक बात पक्की है, आप एक ऐसी गणना कर रहे हैं जो आपको पहली बार में नहीं करनी चाहिए, और परिणाम वास्तविकता से इतना दूर है कि मुझे इसके लिए शब्द भी नहीं मिल रहे हैं।

अगली बड़ी बात इम्पैक्ट मेट्रिक्स है। आपको पता होना चाहिए कि वेब एप्लिकेशन क्या प्रभाव बताने वाला है। लेकिन हम वेब एप्लिकेशन के लिए भेद्यता स्कोर की गणना नहीं कर रहे हैं ... संदर्भ को देखते हुए, इस XSS का Koa पर शून्य प्रभाव है। Koa गोपनीय जानकारी को अपने आप हैंडल या प्रोसेस नहीं करता है। बग का उपलब्धता या अखंडता पर कोई प्रभाव नहीं पड़ता है। गणना में हमले के वेक्टर को मजबूर करने के बाद भी यह हमें 0.0 के अंतिम स्कोर के साथ छोड़ देता है ।

तो सवाल यह है कि हम तथ्यों की रिपोर्ट करते हैं या कल्पना की?

सोनाटाइप ने मेरे ध्यान में सॉफ्टवेयर लाइब्रेरी में स्कोरिंग कमजोरियों के लिए आधिकारिक मार्गदर्शन लाया , जिसे 2019 में CVSSv3.1 के साथ जारी किया गया था। मैं मानता हूं कि मुझे इसके बारे में पता नहीं था, जो अच्छा और बुरा दोनों है। अच्छा है क्योंकि यह एक शेख़ी पोस्ट में परिणत होता, बुरा इसलिए क्योंकि शायद अगर मैंने इसे पहले देखा होता, तो मैं अपनी सारी आशा खो देता, इससे पहले कि मैं समझाने की कोशिश में इतना प्रयास करता कि यह इसके बारे में जाने का सही तरीका नहीं है। तो, आधिकारिक मार्गदर्शन क्या कहता है?

पुस्तकालय में भेद्यता के प्रभाव को स्कोर करते समय ... विश्लेषक को उचित सबसे खराब स्थिति कार्यान्वयन परिदृश्य के लिए स्कोर करना चाहिए। जब संभव हो, सीवीएसएस जानकारी को इन मान्यताओं का विवरण देना चाहिए।

तो उत्तर यह है कि भेद्यता स्कोरिंग कल्पना पर आधारित है।

इसके अलावा, " उचित सबसे खराब स्थिति कार्यान्वयन परिदृश्य" क्या है? यदि हमने कोआ का उपयोग करने वाली कई परियोजनाओं का विश्लेषण किया और पाया कि अधिकांश डेवलपर्स ने कोआ की ctx.redirect()पद्धति का उपयोग करके खुले पुनर्निर्देशन को लागू किया है, तो यह सबसे खराब मान लेना उचित होगा। मैंने गिटहब पर जावास्क्रिप्ट परियोजनाओं में त्वरित कोड खोजctx.redirect( की है। मुझे 16,827 कोड परिणाम मिले। मुझे खोजने पर 15,751 context.redirect(कोड परिणाम प्राप्त हुए। विश्लेषण करने के लिए यह 32,578 कोड परिणाम होंगे। इनमें से कुछ Koa, कुछ Express और कुछ कुछ और इस्तेमाल कर रहे होंगे. (बेशक, संदर्भ को किसी भी नाम से पुकारा जा सकता है, केवल ctxया नहीं context, इसलिए देखने के लिए और भी कोड हो सकते हैं।)

सवाल यह है कि: क्या उपयोगकर्ता द्वारा प्रदान किए गए डेटा को दिमागी तौर पर पुनर्निर्देशित करने के लिए सामान्य रूप से पारित किया जा रहा है? मैंने खोज मापदंड से मेल खाने वाली सभी परियोजनाओं की जांच करने के लिए एक छोटी स्क्रिप्ट लिखकर विश्लेषण के लिए एक अर्ध-स्वचालित दृष्टिकोण अपनाया। दुर्भाग्य से, मैं पहले 1,000 हिट्स को पार नहीं कर सका क्योंकि GitHub ने आगे के अनुरोधों को अस्वीकार कर दिया:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

मैंने जो देखा है उसके आधार पर और अगले खंड ("पुराना वेब ब्राउज़र") में जो चर्चा की गई है, उसके आधार पर, मुझे विश्वास नहीं है कि सबसे खराब स्थिति का कार्यान्वयन उचित होगा। इस विशिष्ट मामले में नहीं।

आधिकारिक मार्गदर्शन यह भी कहता है कि:

प्रभावित पुस्तकालय का उपयोग करते हुए किसी दिए गए कार्यान्वयन में भेद्यता को स्कोर करते समय, उस विशिष्ट कार्यान्वयन के लिए स्कोर की फिर से गणना की जानी चाहिए।

यह उचित है और एक हद तक स्थिति के विज्ञान-कथा पहलू को कम करता है। इस प्रकार यह कोआ मुद्दा, 9.8 के भेद्यता स्कोर के साथ, हमारे मामले में 0.0 पर समाप्त हुआ।

अच्छी बात यह है कि सोनाटाइप ने सहमति व्यक्त की कि 9.8 भेद्यता स्कोर अनुचित था, और वे इसे कम करने को तैयार हैं। मैं इसकी सराहना करता हूं, और शायद कई अन्य लोग भी करेंगे।

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

मैंने कभी सवाल नहीं किया कि सुरक्षा के मुद्दों को संप्रेषित किया जाना चाहिए या नहीं। हां, सुरक्षा मुद्दों को स्पष्ट किया जाना चाहिए। मुझे इस बात की चिंता है कि इन मुद्दों को कैसे संप्रेषित किया जाता है:

क्या किसी चीज़ को भेद्यता कहना उचित है या इसे सुरक्षा कमज़ोरी या असुरक्षित डिफ़ॉल्ट व्यवहार कहना अधिक उपयुक्त है, इत्यादि?
क्या सौंपा गया भेद्यता स्कोर उचित है?
क्या पर्याप्त विवरण और संदर्भ प्रदान किए गए हैं?

अब बात करते हैं पुराने वेब ब्राउजर की।

पुराना वेब ब्राउज़र

सोनाटाइप के अच्छे लोगों के बिना, मैं पुराने वेब ब्राउज़रों के बारे में नहीं सोच पाता, शायद फिर कभी।

मैं भविष्य में भी पुराने ब्राउज़रों पर विचार नहीं करना जारी रखूंगा। सबसे पहले, ध्यान में रखने के लिए बहुत सी चीज़ें हैं; मैं पुराने वेब ब्राउज़रों के बारे में चिंता नहीं कर सकता। दूसरा, एक पुराना वेब ब्राउज़र कितना पुराना है ( यदि आप हास्य की भावना नहीं रखते हैं तो लिंक पर क्लिक न करें! )? "पुराना" वास्तव में क्या मतलब है? यदि कोई केवल ~ 1 वर्ष पुराने ब्राउज़र का उपयोग करता है, तो संभावना है कि उन्हें पहले से ही XSS की तुलना में बहुत बड़ी समस्याएँ हैं।

फिर भी, मैंने कुछ खुदाई की और पाया कि:

2016 (!) से Google क्रोम 48.0.2564.109 (64-बिट) ने प्रतिक्रिया निकाय भी प्रदर्शित नहीं किया। जैसा कि कोआ का मुद्दा 2018 में पाया गया था, मैंने सोचा था कि 2016 तक वापस जाना पर्याप्त होना चाहिए, लेकिन यह निकला कि ऐसा नहीं था।
2011 से फ़ायरफ़ॉक्स 4.0 ने प्रतिक्रिया निकाय प्रदर्शित किया, लेकिन इसके लिए उपयोगकर्ताओं को जावास्क्रिप्ट पेलोड को निष्पादित करने के लिए लिंक पर क्लिक करना आवश्यक था। (बेशक, यह एक लिंक है!)
2017 से Firefox 52.0, Koa XSS समस्या की रिपोर्ट किए जाने के 1 साल पहले, जावास्क्रिप्ट पेलोड के साथ प्रतिक्रिया निकाय प्रदर्शित नहीं किया था। फ़ायरफ़ॉक्स ने "नेटवर्क प्रोटोकॉल उल्लंघन" के कारण "दूषित सामग्री त्रुटि" कहते हुए एक त्रुटि फेंक दी।

Koa 0.0.1 को 2013 में रिलीज़ किया गया था, इसलिए कुछ साल ऐसे थे जब इस मुद्दे का फायदा उठाया जा सकता था, हालाँकि। इसके अनुसार, 2018 में कोआ 2.5.0 तक इस मुद्दे (अभी भी 9.8 स्कोर के साथ नहीं) को ध्वजांकित करना स्वीकार्य होगा। उसके बाद, हालांकि, 1.0 से ऊपर कुछ भी उचित नहीं है।

जब मैं खुदाई कर रहा था, तो मुझे विकिपीडिया पर कुछ दिलचस्प मिला । मुझे उद्धृत करने दो:

फ़ायरफ़ॉक्स 15 को 28 अगस्त, 2012 को जारी किया गया था ... फ़ायरफ़ॉक्स 15 ने साइलेंट अपडेट पेश किया, एक स्वचालित अपडेट जो उपयोगकर्ता को सूचित किए बिना फ़ायरफ़ॉक्स को नवीनतम संस्करण में अपडेट कर देगा, [65] एक ऐसी सुविधा जो वेब ब्राउज़र Google क्रोम और इंटरनेट एक्सप्लोरर 8 और इसके बाद के संस्करण में है पहले से ही लागू

इसलिए कोआ के पहले संस्करण के जारी होने से पहले सभी प्रमुख वेब ब्राउज़रों में एक ऑटो-अपडेट सुविधा थी, जिसका अर्थ है कि अधिकांश उपयोगकर्ता अप-टू-डेट वेब ब्राउज़र का उपयोग कर रहे थे। आइए देखते हैं "बिग बैंग" के समय की स्थिति: 2013।

फ़ायरफ़ॉक्स 15 : "दूषित सामग्री त्रुटि" कहते हुए एक त्रुटि लौटाई, जिसका अर्थ है कि प्रतिक्रिया का मुख्य भाग उपयोगकर्ता को प्रदर्शित नहीं किया गया था।
क्रोम 24.0.1312 (वेबकिट 537.17) : इसने कोई प्रतिक्रिया निकाय प्रदर्शित नहीं किया। डेवलपर टूल के नेटवर्क टैब को देखते समय, मुश्किल से कुछ भी दिखाई दे रहा था, इसलिए मुझे यह देखने के लिए Wireshark चलाना पड़ा कि क्या ब्राउज़र ने पहली बार अनुरोध किया है। Wireshark में, यह दिखाई दे रहा था कि Chrome ने मेरी PoC सेवा से संपर्क किया और JavaScript पेलोड के साथ प्रतिक्रिया प्राप्त की। इसने प्रतिक्रिया निकाय प्रस्तुत नहीं किया। इससे भी अच्छा, कुछ नहीं हुआ।
इंटरनेट एक्सप्लोरर 11 (11.0.9600.19180) : इसने मेरी PoC सेवा से प्रतिक्रिया प्राप्त की, जिसे मैंने Wireshark का उपयोग करके सत्यापित किया। इसने उपयोगकर्ता को प्रतिक्रिया निकाय नहीं दिखाया। यह शास्त्रीय, अंतर्निहित त्रुटि पृष्ठ के साथ लौटा, जो कहता है, "यह पृष्ठ प्रदर्शित नहीं किया जा सकता"।

उपरोक्त शोध करने के बाद, चलिए एक सेकंड के लिए सोनाटाइप के एक उद्धरण पर वापस आते हैं:

जबकि यह कथन सही है, तथ्य यह है कि कोआ के पहले संस्करण के जारी होने तक किसी भी प्रमुख ब्राउज़र ने शोषण की अनुमति नहीं दी थी, उद्धृत कुछ दिलचस्प सुझाव देता है, वाक्य के अलावा कुछ और जो सुझाव देना चाहता है। कृपया ध्यान दें कि मैं अटकलें लिखने वाला हूं क्योंकि मैं ठीक से नहीं जान सकता कि कोआ डेवलपर्स कैसे सोच रहे थे। मैं आसानी से कल्पना कर सकता हूं कि डेवलपर ने अप-टू-डेट वेब ब्राउज़र का उपयोग करके व्यवहार का परीक्षण किया था। hrefहो सकता है कि उन्होंने पाया हो कि HTML एन्कोडिंग उपयुक्त थी क्योंकि इसकी संपत्ति से इंजेक्ट किए गए जावास्क्रिप्ट कोड को निष्पादित करना पहले से ही असंभव थाaटैग। यह एक गंभीर सवाल खड़ा करता है। सॉफ्टवेयर विकास पक्ष पर पिछले पांच साल अधिक खर्च करने के बाद, यह मुझ पर भी लागू होता है: एक डेवलपर के रूप में, अगर मैं बैकएंड साइड के लिए एक नई वेब तकनीक बनाने जा रहा हूं, तो क्या मुझे पुराने वेब ब्राउज़रों की परवाह करनी चाहिए? और अगर मुझे करना चाहिए, तो सुरक्षा समुदाय से आधिकारिक सिफारिश क्या है कि मुझे कितने पुराने वेब ब्राउज़रों पर विचार करना चाहिए? क्या हमें इस बात पर विचार नहीं करना चाहिए कि एंड-यूजर्स के लिए सुरक्षा का सर्वोत्तम अभ्यास अपने ब्राउज़र को अद्यतित रखना है, और इसमें मदद करने के लिए ऑटो-अपडेट सुविधा भी है? इसके अलावा, अगर हम डेवलपर्स से पुराने ब्राउज़रों को ध्यान में रखने और परीक्षण करने की उम्मीद करते हैं, तो क्या हम सुरक्षा पेशेवरों से ऐसा करने की अपेक्षा नहीं कर सकते हैं और सभी वेब ब्राउज़रों और उनके संस्करणों को नाम दें जो किसी विशिष्ट समस्या में योगदान करते हैं, बजाय केवल "पुराने ब्राउज़रों" का जिक्र करने के। ”? यह उचित ही होगा।

एक बात तो तय है कि अब सालों से चिंता की कोई बात नहीं है...

आधुनिक ब्राउज़र

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

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

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

आगामी परिवर्तन

इस मुद्दे के संबंध में सोनाटाइप लागू करने की योजना बना रहा है अद्यतनों की सूची नीचे दी गई है:

गलतफहमी को खत्म करने के लिए सारांश/शीर्षक पंक्ति का अद्यतन (पहले ही हो चुका है)
भेद्यता स्कोर को 4.7 तक कम करना (पहले ही हो चुका है)
उल्लेख करें कि भेद्यता का केवल तभी फायदा उठाया जा सकता है जब कोई उपयोगकर्ता पुराना ब्राउज़र चला रहा हो

अतिरिक्त परिवर्तन जो मैं देखना चाहूंगा

पिछले अनुभाग में उल्लिखित परिवर्तनों के शीर्ष पर, कुछ चीज़ों में और सुधार किया जा सकता है। य़े हैं:

भेद्यता स्कोर को और कम करना, विशेष रूप से 2018 के बाद जारी किए गए Koa संस्करणों के लिए।
"पुराने ब्राउज़र" का संदर्भ देते समय रिपोर्ट में कम से कम प्रमुख वेब ब्राउज़रों की संस्करण संख्या और उनकी रिलीज़ तिथियां शामिल हैं। यह "प्रभावित पुस्तकालय का उपयोग करके दिए गए कार्यान्वयन में भेद्यता को स्कोर करने" में किसी की भी मदद करेगा। उदाहरण के लिए, यदि मैंने देखा कि किसी उपयोगकर्ता को 2011 से एक ब्राउज़र का उपयोग करना था, तो मैं एससीए में एक सेकंड के भीतर इस मुद्दे को "प्रभावित नहीं" के रूप में चिह्नित कर देता। बहुत समय बच गया है।
प्रभावित Koa संस्करणों को भेद्यता के पृष्ठ पर सूचीबद्ध किया जाना है ।

वैसे, सोनटाइप ने यह भी उल्लेख किया कि उनकी व्यावसायिक पेशकश में कुछ अच्छे चेक हैं, उदाहरण के लिए, कोड स्तर पर वास्तविक जांच करते हैं ताकि यह देखा जा सके कि रिपोर्ट की गई कमजोरियों से कोई एप्लिकेशन प्रभावित हुआ था या नहीं। यह साफ-सुथरा लगता है, और पुस्तकालयों के लिए भेद्यता स्कोर की गणना कैसे की जाती है, इसकी विज्ञान-कथा प्रकृति को देखते हुए, इंजीनियरिंग टीमों पर भार को कम करने के लिए इस प्रकार के चेक अनिवार्य हैं, खासकर अगर चीजें इसी तरह जारी रहती हैं।

निष्कर्ष

मेरे पास लगभग सभी अपडेट हैं। मुझे खुशी है कि मैंने सोनाटाइप से संपर्क किया क्योंकि वे बहुत पेशेवर और मिलनसार हैं। इस पर उनके साथ काम करके बहुत खुशी हुई।

Koa में XSS के बारे में: यह कुछ ऐसा है जिसके बारे में हममें से किसी को भी कई वर्षों से चिंतित नहीं होना चाहिए था।