pentagridsec/pentagridresponseoverviewResponse Overview Extension for BurpSuite - प्रतिक्रिया निकायों को समूहीकृत करके विदेशी प्रतिक्रियाएँ खोजें
BurpSuite के लिए Response Overview एक्सटेंशन
लेखक: Tobias "floyd" Ospelt, @floyd_ch, http://www.floyd.ch
Pentagrid AG, https://www.pentagrid.ch
यह एक्सटेंशन सभी रिस्पॉन्स बॉडीज़ को समानता के आधार पर समूहीकृत करता है और एक सारांश दिखाता है, प्रत्येक समूह के लिए एक रिक्वेस्ट/रिस्पॉन्स। यह एक्सटेंशन परीक्षक को सभी टूल्स (स्कैनर, प्रॉक्सी, आदि) से परीक्षण की गई वेबसाइट के रिस्पॉन्स का अवलोकन प्राप्त करने की अनुमति देता है। यह एक अतिरिक्त "अर्ध-स्वचालित डिटेक्शन विधि" प्रदान करता है (सामान्य डिटेक्शन विधियों जैसे रिस्पॉन्स-आधारित, समय-आधारित, इंटरैक्शन-आधारित, आदि की तुलना में)। विभिन्न अनुकूलन हैं, मुख्यतः प्रदर्शन कारणों से। "remove parameters" सुविधा तुलना से पहले रिस्पॉन्स से प्रतिबिंबित रिक्वेस्ट पैरामीटर हटा देती है।
अब तक:
उपयोग बहुत सरल है:
यह एक्सटेंशन HTTP रिस्पॉन्स का विश्लेषण करता है यदि:
जब उपरोक्त फ़िल्टर बाधाएं संतुष्ट होती हैं, तो आने वाली रिस्पॉन्स बॉडीज़ (सभी Burp टूल्स से!) की तुलना उन सभी समूहों से की जाती है जो हम पहले ही बना चुके हैं। एक समूह को उसके पहले सदस्य द्वारा परिभाषित किया जाता है, जिसे हम मेमोरी में रखते हैं। यदि हम जिस रिस्पॉन्स को प्रोसेस कर रहे हैं वह उस पहले सदस्य से 95% समान है, तो यह उस समूह से संबंधित है और केवल "Group Size" काउंटर बढ़ाया जाता है। इसका मतलब यह भी है कि हम उस रिस्पॉन्स को संग्रहीत नहीं करेंगे। यदि रिस्पॉन्स किसी भी समूह से 95% समान नहीं है, तो यह एक नया समूह बनाता है और यह उसका पहला सदस्य है।
ऐसे रिस्पॉन्स ओवरव्यू का पहला संस्करण जो आपको विसंगतियों को खोजने की अनुमति देता है, मैंने 2010 में w3af प्रोजेक्ट को प्रस्तावित किया था (यहां एक चर्चा भी देखें: https://github.com/andresriancho/w3af/issues/17345) और यह Python में लिखा गया था। यह कभी मुख्यधारा w3af में शामिल नहीं हुआ, मुझे याद नहीं क्यों। उस समय मैंने Python के difflib के बारे में बहुत कुछ सीखा और उपयोग केस के लिए प्रदर्शन को अनुकूलित किया। मैंने 2019 में Burp के लिए Python में एक समान एक्सटेंशन लिखा और जब मैं modzero AG https://github.com/modzero/burp-ResponseClusterer के लिए काम कर रहा था तब फिर से Python के difflib के बारे में बहुत कुछ सीखा। हालांकि, एक बिंदु पर मुझे एहसास हुआ कि एक्सटेंशन Burp के प्रदर्शन का कुछ हिस्सा खा सकता है, जिसे मैंने पहले नजरअंदाज कर दिया था। 2021 में एक्सटेंशन पूरी तरह से टूट गया क्योंकि यह नए Jython संस्करणों के साथ नहीं चलता था और कोड को फिर से देखते समय मुझे एहसास हुआ कि मैंने एक बहुत ही मेमोरी-अक्षम एक्सटेंशन कोड किया था। तो यहाँ हम हैं, यह 2021 में Kotlin में एक नया एक्सटेंशन है जिसमें नई सुविधाएं हैं, फिर से Python के difflib और विभिन्न सुविधाओं से बहुत कुछ सीख रहे हैं। मैंने एक प्रदर्शन सुधार किया क्योंकि मुझे एहसास हुआ कि कुछ गणनाएं आवश्यक नहीं हैं यदि हम हमेशा समान स्ट्रिंग्स की तुलना करते हैं (जैसा कि Python कोड में पहले से लागू है)। Response Clusterer मर गया, Response Overview की जय हो।
सिद्धांत रूप में, डिफ़ॉल्ट सेटिंग्स के परिणामस्वरूप Burp का प्रदर्शन बहुत अच्छा नहीं हो सकता है। हालांकि, ऐसा होने की संभावना बहुत कम है। एक परीक्षण जिसमें सभी रिस्पॉन्स का अधिकतम डिफ़ॉल्ट रिस्पॉन्स आकार (लगभग 1MB) था, उनकी एक-दूसरे से तुलना करनी पड़ी, तुलना में precalculated bByteCount अनुकूलन के साथ 30ms तक का समय लगा (सामान्य मामला) और इस अनुकूलन के बिना 80ms तक (प्रत्येक प्रविष्टि के लिए केवल एक बार होता है)। समूहों की अधिकतम संख्या (1000) से गुणा करने पर इसका मतलब है कि पूर्णतया सबसे खराब स्थिति में यह 80 सेकंड तक प्रोसेसिंग समय का मतलब हो सकता है। चूंकि एक अलग थ्रेड है, यह सहनीय होगा, क्योंकि अगली तुलना में तब अधिकतम 30 सेकंड का समय लगेगा। लेकिन किस वेब एप्लिकेशन में लगभग 1MB के कई अलग-अलग रिस्पॉन्स होते हैं? चलो उम्मीद करते हैं कि बहुत अधिक नहीं। यह भी न भूलें कि यदि रिस्पॉन्स की लंबाई 2% से अधिक भिन्न होती है, तो veryQuickRatio अनुकूलन के कारण समानता मिलान में कोई समय नहीं लगता है।
