मेनू सिस्टम एक समर्पित कॉन्फ़िगरेशन/सेटअप मॉड्यूल में लागू किया जाएगा। यह बस एक फ़ंक्शन हो सकता है जो प्रॉम्प्ट प्रिंट करता है और इनपुट एकत्र करता है, यदि उपयोगकर्ता Enter दबाता है तो उचित डिफ़ॉल्ट के साथ (जैसे, डिफॉल्ट user-agent एक मानक पर, डिफ़ॉल्ट टाइमआउट = 10 सेकंड, कोई प्रॉक्सी नहीं, कोई फ़ाइल आउटपुट नहीं)। यह इंटरैक्शन को स्पष्ट रखता है और स्क्रिप्ट को गैर-इंटरैक्टिव रूप से चलाने की अनुमति भी देता है (यदि हम बाद में कमांड-लाइन आर्ग्स जोड़ते हैं, तो हम सभी आवश्यक कॉन्फ़िगरेशन args के माध्यम से प्रदान करके इंटरैक्टिव प्रॉम्प्ट को बायपास कर सकते हैं)।

🚀 समवर्तीता और प्रदर्शन संवर्द्धन

प्रदर्शन एक स्कैनर के लिए महत्वपूर्ण है, खासकर यदि कई एंडपॉइंट पाए जाते हैं। स्क्रिप्ट गति के लिए समवर्तीता का उपयोग करेगी, या तो मल्टी-थ्रेडिंग या asyncio (या एक संयोजन) के माध्यम से:

• मल्टी-थ्रेडेड स्कैनिंग: चूंकि खोजे गए पथों का स्कैन करना (हेडर के साथ HTTP अनुरोध भेजना) एक I/O-बाउंड कार्य है, हम इसे समानांतर करने के लिए Python थ्रेड्स का सुरक्षित रूप से उपयोग कर सकते हैं। I/O संचालन ग्लोबल इंटरप्रेटर लॉक को जारी करते हैं, जिससे कई थ्रेड्स एक साथ नेटवर्क अनुरोधों पर प्रगति कर सकते हैं। concurrent.futures.ThreadPoolExecutor का उपयोग करके, हमारे पास वर्कर थ्रेड्स का एक पूल हो सकता है जो स्कैनिंग कार्यों के एक उपसमूह को संभालता है। यह प्रक्रिया को नाटकीय रूप से गति दे सकता है: उदाहरण के लिए, समानांतर में 5 थ्रेड चलाने से स्कैनिंग का समय लगभग 5 के कारक से कम हो सकता है, जैसा कि अन्य वेब स्क्रैपिंग संदर्भों में दिखाया गया है। हम थ्रेड्स की संख्या को कॉन्फ़िगरेबल होने देंगे या गति और सर्वर लोड को संतुलित करते हुए एक उचित डिफ़ॉल्ट (जैसे 10 थ्रेड) चुनेंगे। प्रत्येक थ्रेड परीक्षण करने के लिए एंडपॉइंट्स की साझा कतार से URL लेगा।

• Asyncio विकल्प: वैकल्पिक रूप से, एक एसिंक्रोनस दृष्टिकोण का उपयोग किया जा सकता है, खासकर यदि Playwright को async मोड में या HTTP अनुरोधों के लिए httpx का उपयोग किया जाता है। हम एक साथ कई अनुरोधों की await कर सकते हैं। उदाहरण के लिए, httpx.AsyncClient एक साथ कई अनुरोध भेज सकता है और परिणाम एकत्र कर सकता है। यह दृष्टिकोण थ्रेड ओवरहेड से बचता है और बड़ी संख्या में एंडपॉइंट्स के लिए बहुत कुशल हो सकता है। हालांकि, asyncio को Playwright के साथ मिलाना (जिसका उपयोग स्वयं एसिंक्रोनस रूप से किया जा सकता है) चीजों को जटिल बना सकता है। एक व्यावहारिक समाधान HTTP स्कैन चरण के लिए थ्रेडिंग का उपयोग करना है (क्योंकि Playwright के साथ क्रॉलिंग को सिंक्रोनस मोड में प्रबंधित करना आसान हो सकता है)।

• समवर्ती क्रॉलिंग: हमें क्रॉल को भी समानांतर करने पर विचार करना चाहिए यदि साइट बड़ी है। Playwright async कॉन्टेक्स्ट का उपयोग करके एक साथ कई पेज खोल सकता है। हम क्रॉलिंग के लिए एक सीमित समवर्तीता (जैसे, एक समय में 2-3 पेज) लागू कर सकते हैं। उदाहरण के लिए, जैसे ही हम नए URL निकालते हैं, हम asyncio का उपयोग करके प्रत्येक के लिए एक नया पेज लॉन्च कर सकते हैं। यदि आवश्यक हो तो यह एक उन्नत अनुकूलन हो सकता है। प्रारंभ में, एक सिंगल-थ्रेडेड क्रॉल सरल है और मध्यम आकार की साइटों के लिए ठीक है, लेकिन डिज़ाइन इसे एक संवर्द्धन बिंदु के रूप में नोट कर सकता है।

• थ्रेड-सुरक्षा: हम साझा डेटा के थ्रेड-सुरक्षित हैंडलिंग को सुनिश्चित करेंगे। स्कैन करने के लिए URL की सूची को सादगी के लिए ThreadPoolExecutor.map के साथ संसाधित किया जा सकता है, या हम एक थ्रेड-सुरक्षित कतार (Python की queue.Queue) का उपयोग कर सकते हैं और थ्रेड्स को खाली होने तक उसमें से खींचने दे सकते हैं। क्रॉलिंग के लिए visited सेट केवल क्रॉलर (सिंगल थ्रेड, जब तक हम समवर्ती क्रॉलिंग नहीं करते) द्वारा एक्सेस किया जाता है। स्कैनर थ्रेड केवल अपने URL की सूची से पढ़ेंगे (शायद लॉगिंग परिणामों को छोड़कर कोई साझा संरचना संशोधित नहीं करेंगे, जिसे हम लॉक के साथ सुरक्षित कर सकते हैं या बस थ्रेड-सुरक्षित सूची में एकत्र कर सकते हैं)।

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

संक्षेप में, समवर्तीता मुख्य रूप से स्कैनिंग चरण पर लागू की जाएगी ताकि समानांतर में कई एंडपॉइंट्स का परीक्षण किया जा सके। यह स्कैनर को सटीकता का त्याग किए बिना बहुत तेज़ बनाता है (क्योंकि प्रत्येक अनुरोध स्वतंत्र है)। जैसा कि एक संदर्भ नोट करता है, “concurrent.futures के साथ मल्टीथ्रेडिंग यहां एक महत्वपूर्ण बढ़ावा दे सकता है। हम कई थ्रेड्स में I/O कार्यों को समवर्ती रूप से निष्पादित कर सकते हैं और एक बड़ी गति देख सकते हैं”। मल्टी-थ्रेडिंग यहां उपयुक्त है क्योंकि नेटवर्क-बाउंड कार्य Python में भी इससे लाभान्वित होते हैं।

🚀 मुख्य स्कैनिंग तर्क: भेद्यता के लिए एंडपॉइंट्स का परीक्षण

स्क्रिप्ट का हृदय स्कैनिंग मॉड्यूल है, जो खोजे गए एंडपॉइंट्स (पथों) की सूची लेता है और CVE-2025-29927 भेद्यता के संकेतों के लिए प्रत्येक की जांच करता है। प्रत्येक एंडपॉइंट के लिए प्रक्रिया होगी:

• 1. आधारभूत अनुरोध: सामान्य उपयोगकर्ता अनुरोध का अनुकरण करते हुए, विशेष हेडर के बिना एंडपॉइंट पर एक HTTP GET अनुरोध भेजें। तुलना के लिए स्थिति कोड और प्रतिक्रिया निकाय की लंबाई (या निकाय का हैश) रिकॉर्ड करें। किसी भी दिलचस्प प्रतिक्रिया हेडर को भी नोट करें। विशेष रूप से, यदि प्रतिक्रिया में x-middleware-rewrite, x-middleware-next, या x-middleware-redirect जैसे Next.js के मिडलवेयर हेडर में से कोई है, तो यह सुझाव देता है कि यह रूट मिडलवेयर द्वारा संरक्षित है। हम यह भी जांचते हैं कि क्या स्थिति 200 नहीं है (जिसका अर्थ है कि पहुंच अस्वीकार कर दी गई या रीडायरेक्ट किया गया), क्योंकि ये वे हैं जिनके बायपास होने की संभावना है। (यदि स्थिति पहले से 200 है और सामग्री सामान्य रूप से लोड होती है, तो यह या तो एक सार्वजनिक पृष्ठ है या भेद्यता लागू नहीं होती है; हम फिर भी इसका परीक्षण कर सकते हैं, लेकिन वास्तविक रुचि संरक्षित पृष्ठों में है।)
• 2. दुर्भावनापूर्ण अनुरोध तैयार करें: उसी एंडपॉइंट पर अतिरिक्त अनुरोध भेजें, इस बार X-Middleware-Subrequest हेडर शामिल करके। हम Next.js संस्करणों में पहचान सुनिश्चित करने के लिए विभिन्न हेडर मानों का प्रयास करेंगे:

• एक सामान्य मान जैसे "1" या "true" (कुछ स्रोतों का तात्पर्य है कि केवल हेडर को किसी भी मान पर सेट करना छोड़ने को ट्रिगर करता है)।

• सार्वजनिक शोषणों में उपयोग किया जाने वाला विशिष्ट पेलोड, उदा., "middleware:middleware:middleware:middleware:middleware" (पांच बार "middleware" की पुनरावृत्ति)। यह नवीनतम संस्करणों (13+) के लिए बायपास प्रेरित करने के लिए जाना जाता है। हम बिल्कुल यह मान शामिल करेंगे।

• /src निर्देशिका का उपयोग करने वाली परियोजनाओं के लिए वैकल्पिक पेलोड, उदा., "src/middleware:src/middleware:src/middleware:src/middleware:src/middleware"

• वैकल्पिक रूप से, पूर्णता के लिए एकल-खंड मान जैसे "middleware" या "src/middleware" (पुराने Next.js संस्करण पृष्ठ निर्देशिका में एक _middleware फ़ाइल का उपयोग कर सकते हैं, थोड़े अलग आवश्यक पेलोड के साथ, लेकिन उपरोक्त बहु-खंड पेलोड बड़े पैमाने पर ज्ञात मामलों को कवर करते हैं)। इनमें से प्रत्येक अनुरोध कस्टम हेडर सेट करके किया जाएगा। हम आधारभूत से उसी विधि (GET) का उपयोग करना और किसी भी हेडर को शामिल करना सुनिश्चित करेंगे जो आवश्यक हो सकते हैं (जैसे कुकीज़ या प्रमाणीकरण टोकन यदि उपयोगकर्ता ने लॉग-इन स्कैन के लिए प्रदान किया है, हालांकि आमतौर पर हम अप्रमाणित के रूप में स्कैन करते हैं)।

• 3. प्रतिक्रियाओं की तुलना करें: प्रत्येक हेडर परीक्षण के लिए, प्रतिक्रिया की आधारभूत से तुलना करें:

• यदि आधारभूत एक त्रुटि या रीडायरेक्ट था (जैसे, 401 अनधिकृत, 403 निषिद्ध, या लॉगिन के लिए रीडायरेक्ट) और हेडर-इंजेक्टेड प्रतिक्रियाओं में से एक 200 OK है जिसमें काफी बड़ा निकाय है (या अन्यथा संकेत देता है कि पृष्ठ लोड हुआ), तो यह भेद्यता का एक मजबूत संकेतक है। उदाहरण के लिए, यदि /admin सामान्यतः 403 लौटाता है, लेकिन हेडर के साथ 200 लौटाता है और इसमें एडमिन डैशबोर्ड HTML है, तो हम इसे फ़्लैग करते हैं।

• कुछ मामलों में, अंतर 302 बनाम 200, या 404 बनाम 200 हो सकता है। हम एक गैर-200 से 200 तक स्थिति कोड परिवर्तन को एक संभावित संकेत मानेंगे। साथ ही, यदि स्थिति 200 ही रहता है लेकिन सामग्री की लंबाई नाटकीय रूप से बदलती है, तो यह संकेत दे सकता है कि हेडर ने व्यवहार को बदल दिया (इस विशेष बग के लिए कम सामान्य, लेकिन एक संभावना यदि पृष्ठ सामान्यतः एक चीज़ देता था और हेडर के साथ दूसरी देता था)।

• हम ऐसी जांचें लागू करेंगे जैसे: if base_status_code != 200 and test_status_code == 200: (और शायद यह भी सुनिश्चित करें कि test_body_length > base_body_length या इसमें कोई प्रमाणित कीवर्ड है) तो कमजोर के रूप में फ़्लैग करें। यदि आधारभूत एक रीडायरेक्ट था (जैसे, /login के लिए 307), और परीक्षण 200 देता है, तो भी फ़्लैग करें। मूलतः, “क्या पहुंच पहले अस्वीकार कर दी गई थी लेकिन अब अनुमति है?”

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

• 4. परिणाम लॉग करना: परीक्षण किए गए प्रत्येक एंडपॉइंट के लिए, स्क्रिप्ट परिणाम लॉग करेगी। यदि कोई अंतर नहीं पाया जाता है (कमजोर नहीं), तो हम इसे एक वर्बोज़ लॉग में रख सकते हैं या त्याग सकते हैं। यदि एक संभावित भेद्यता पाई जाती है, तो हम एंडपॉइंट, आधारभूत स्थिति, और किस हेडर मान ने 200 दिया, आदि रिकॉर्ड करते हैं। इन्हें कंसोल पर प्रिंट किया जाएगा और यदि उपयोगकर्ता ने परिणाम सहेजने का विकल्प चुना है तो results.txt में सहेजा जाएगा। हमें इसे स्पष्ट रूप से स्वरूपित करना चाहिए, उदा.:

• [*] /admin -> baseline 403, with X-Middleware-Subrequest (payload X) got 200 [VULNERABLE]

• हम प्रतिक्रिया की लंबाई या प्रतिक्रिया का एक स्निपेट भी प्रिंट कर सकते हैं ताकि पुष्टि हो सके (शायद संक्षिप्तता के लिए केवल लंबाई, जैसे, “len: 0 -> 10240 bytes”)। यदि कई पेलोड का प्रयास किया गया था, तो हम सूचीबद्ध कर सकते हैं कि कौन सा सफल हुआ।

• यदि साइट बिल्कुल भी Next.js एप्लिकेशन नहीं लगती है (जैसे, हमें होमपेज पर कोई /_next/static/ नहीं मिला, जो एक स्पष्ट संकेत है), तो हम एक नोट आउटपुट कर सकते हैं: “No Next.js indicators found, the target may not be using Next.js – likely not vulnerable.” लेकिन हम फिर भी सामान्य रूप से आगे बढ़ सकते हैं, क्योंकि Next.js जांच एक आवश्यकता के बजाय एक अनुकूलन है।यह तर्क साफ-साफ समाहित किया जाएगा। उदाहरण के लिए, हमारे पास एक फ़ंक्शन scan_endpoint(url, session, header_payloads) हो सकता है जो एक रिज़ल्ट ऑब्जेक्ट या डिक्ट लौटाता है जिसमें यह बताया जाता है कि यह कमजोर है या नहीं और विवरण दिए जाते हैं। हम झूठी सकारात्मकता (false positives) से बचने के लिए मजबूत जाँच शामिल करेंगे। विशेष रूप से, स्टेटस कोड में 200 (या अन्य स्पष्ट सबूत) का परिवर्तन आवश्यक होने से यह सुनिश्चित करने में मदद मिलती है कि हम केवल वास्तविक बाइपास को चिह्नित करें। जैसा कि ProjectDiscovery के विश्लेषण में उल्लेख किया गया है, स्कैनर कमजोरी की पुष्टि करने के लिए विशेष हेडर शामिल होने पर रिस्पॉन्स स्टेटस 200 की जाँच करता है​।

🚀 आउटपुट फ़ॉर्मेटिंग और रिपोर्टिंग

स्क्रिप्ट का आउटपुट पढ़ने और व्याख्या करने में आसान होना चाहिए, और वैकल्पिक रूप से एक फ़ाइल में सहेजा भी जा सकता है। हम कंसोल आउटपुट को स्पष्ट शीर्षकों और उपयुक्त इंडेंटेशन के साथ फ़ॉर्मेट करेंगे। कुछ विचार:

• स्कैन के बाद, निष्कर्षों का सारांश प्रिंट करें। उदाहरण के लिए: “स्कैन पूर्ण: 45 में से 3 कमजोर एंडपॉइंट पाए गए।” फिर कमजोर एंडपॉइंट्स को विवरण सहित सूचीबद्ध करें।

• प्रत्येक परिणाम पंक्ति के लिए एक समान प्रारूप का उपयोग करें, जैसा ऊपर दिखाया गया है, संभवतः ध्यान आकर्षित करने के लिए [VULNERABLE] टैग के साथ। यदि rich जैसी लाइब्रेरी का उपयोग कर रहे हैं, तो हम “VULNERABLE” को लाल या पीले रंग में कोड कर सकते हैं। अतिरिक्त लाइब्रेरी के बिना भी, हम हाइलाइट करने के लिए colorama के माध्यम से ANSI कोड का उपयोग कर सकते हैं, या सिर्फ अपरकेस टेक्स्ट।

• यदि कोई कमजोरी नहीं मिलती है, तो स्पष्ट रूप से कहें: “CVE-2025-29927 के लिए कोई कमजोरी का पता नहीं चला।”

• यदि परिणाम सहेजने हैं, तो सुनिश्चित करें कि वे फ़ाइल में समान प्रारूप में लिखे गए हैं। संभवतः थोड़े अधिक विस्तृत तरीके से या प्रोग्रामेटिक उपयोग के लिए CSV में, लेकिन चूंकि उपयोगकर्ता ने विशेष रूप से टेक्स्ट फ़ाइल का उल्लेख किया है, हम संभवतः उन्हीं पंक्तियों को results.txt में लिखेंगे।

• इसके अलावा, किसी भी गंभीर त्रुटि या अपवाद (जैसे किसी पृष्ठ को लोड करने में असमर्थता) को आउटपुट में सुंदर तरीके से रिपोर्ट किया जा सकता है (स्टैक ट्रेस के बजाय)। हम अपवादों को पकड़ सकते हैं और प्रति विफल URL पर एक-पंक्ति चेतावनी प्रिंट कर सकते हैं: जैसे, “Timeout loading /blog (skipped)”। इस तरह, उपयोगकर्ता को पता चल जाएगा कि कुछ पथों का परीक्षण नहीं किया गया।

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

स्पष्ट प्रारूप पर जोर देते हुए, कई परिणाम प्रिंट करते समय बुलेट पॉइंट या तालिका लेआउट का उपयोग मदद कर सकता है:

• हम इस रूप में तालिका बना सकते हैं: Endpoint | Base Status | Base Length | Bypass Status | Bypass Length | HeaderValueUsed | Result

• हालांकि, एक सरल वाक्य रूप उपयोगकर्ताओं की एक विस्तृत श्रृंखला के लिए अधिक पठनीय हो सकता है। हम सुनिश्चित करेंगे कि प्रत्येक परिणाम एक नई पंक्ति पर हो और स्पष्ट रूप से लेबल किया गया हो।

स्क्रीन आउटपुट और वैकल्पिक फ़ाइल सहेज दोनों प्रदान करके, यह उपकरण इंटरैक्टिव उपयोग और स्वचालित स्कैनिंग (जहाँ उपयोगकर्ता बाद में फ़ाइल की समीक्षा कर सकता है या रिपोर्ट में शामिल कर सकता है) दोनों के लिए उपयोगी है।

🚀 मॉड्यूलर कोड संरचना और सर्वोत्तम अभ्यास

स्क्रिप्ट को बनाए रखने योग्य और पेशेवर-ग्रेड बनाने के लिए, हम कोड को मॉड्यूल में व्यवस्थित करेंगे, प्रत्येक कार्यक्षमता के एक विशिष्ट पहलू को संभालेगा। एक संभावित प्रोजेक्ट संरचना:

• crawler.py: इसमें Playwright का उपयोग करके क्रॉलिंग लॉजिक है। इसमें crawl_site(start_url, config) -> List[str] जैसे फ़ंक्शन होंगे जो खोजे गए आंतरिक पथों की सूची लौटाते हैं। यह मॉड्यूल ब्राउज़र लॉन्च करने, पृष्ठों को पुनः प्राप्त करने, लिंक निकालने और फ़िल्टर (डोमेन, स्थैतिक फ़ाइल बहिष्करण) लागू करने का काम संभालेगा। इसमें URL को सामान्य करने के लिए हेल्पर लॉजिक भी हो सकता है (जैसे, URL अंश हटाना, urllib.parse.urljoin के माध्यम से सापेक्ष पथ को संभालना)।

• scanner.py: इसमें कमजोरी के लिए स्कैनिंग लॉजिक है। इसमें scan_paths(url_list, config) -> List[ScanResult] जैसे फ़ंक्शन शामिल होंगे। यह HTTP अनुरोध बनाने (requests.Session या httpx क्लाइंट का उपयोग करके), हेडर लागू करने, प्रतिक्रियाओं की तुलना करने और परिणाम एकत्र करने का प्रबंधन करेगा। यदि मल्टीथ्रेडिंग का उपयोग कर रहे हैं, तो यह मॉड्यूल ThreadPool बनाएगा और कार्यों का प्रबंधन करेगा। यह प्रत्येक पथ के बारे में जानकारी रखने के लिए एक छोटा ScanResult डेटा क्लास परिभाषित कर सकता है (path, vulnerable: bool, details)।

• config.py (या settings.py): इसमें उपयोगकर्ता मेनू और कॉन्फ़िगरेशन के लिए कोड है। उदाहरण के लिए, एक फ़ंक्शन get_user_config() जो उपयोगकर्ता के साथ इंटरैक्ट करता है और सभी चुनी गई सेटिंग्स (user_agent, timeout, proxy, output_file flag, आदि) के साथ एक कॉन्फ़िग ऑब्जेक्ट/डिक्शनरी लौटाता है। यदि CLI args का उपयोग कर रहे हैं, तो यह मॉड्यूल वैकल्पिक रूप से argparse.ArgumentParser को पार्स कर सकता है। मूल रूप से, यह भाग सभी उपयोगकर्ता इनपुट और कॉन्फ़िगरेशन हैंडलिंग को अलग करता है।

• utils.py: उपयोगिता फ़ंक्शन, उदा., बैनर प्रिंट करने, आउटपुट स्ट्रिंग फ़ॉर्मेट करने, रंग आउटपुट संभालने, या सामान्य हेल्पर जैसे is_static_resource(url) (यह जाँचने के लिए कि URL संभवतः किसी स्थैतिक फ़ाइल की ओर इंगित करता है)। इसके अलावा, सुचारू शटडाउन के लिए एक फ़ंक्शन शामिल कर सकते हैं (SIGINT पर कॉल करने के लिए)।

• main.py: एंट्री-पॉइंट स्क्रिप्ट जो सब कुछ एक साथ जोड़ती है। यह:

• 1. उपयोगकर्ता कॉन्फ़िगरेशन को पार्स या एकत्र करेगा (config.py का उपयोग करके)।
• 2. एंडपॉइंट्स की सूची प्राप्त करने के लिए क्रॉलर को कॉल करेगा।
• 3. उन एंडपॉइंट्स का परीक्षण करने के लिए स्कैनर को कॉल करेगा।
• 4. परिणाम प्राप्त करेगा और उन्हें अनुरोधित प्रारूप में आउटपुट करेगा।
• 5. सुनिश्चित करेगा कि कोई भी सफ़ाई (ब्राउज़र बंद करना, फ़ाइलें बंद करना आदि) की गई है। यदि एकल स्क्रिप्ट के रूप में वितरित कर रहे हैं, तो main एक फ़ाइल के निचले भाग में हो सकता है, लेकिन सफ़ाई के लिए अलग करना बेहतर है।

प्रत्येक मॉड्यूल को मॉड्यूलर और पुन: प्रयोज्य बनाने के लिए डिज़ाइन किया जाएगा। उदाहरण के लिए, कोई अन्य उद्देश्यों के लिए साइट लिंक प्राप्त करने के लिए crawler.py का पुन: उपयोग कर सकता है, या दिए गए URL की सूची पर इस कमजोरी का परीक्षण करने के लिए scanner.py का पुन: उपयोग कर सकता है (बिना क्रॉलिंग के भी)।

अपवाद हैंडलिंग और सुचारू शटडाउन: हम मजबूत अपवाद हैंडलिंग लागू करेंगे:

• नेटवर्क संचालन के आसपास try/except (समय समाप्ति, कनेक्शन त्रुटियों आदि को पकड़ें)। यदि किसी पृष्ठ का क्रॉल विफल होता है, तो इसे लॉग करें और दूसरों के साथ जारी रखें। यदि कोई स्कैन अनुरोध विफल होता है (जैसे, प्रॉक्सी त्रुटि), तो उस एंडपॉइंट को त्रुटि के रूप में चिह्नित करें लेकिन बाकी स्कैन करना जारी रखें।

• संसाधनों की सफाई सुनिश्चित करने के लिए finally ब्लॉक या संदर्भ प्रबंधकों का उपयोग करें। उदाहरण के लिए, async_playwright() संदर्भ का उपयोग करें या सुनिश्चित करें क्रॉलिंग के अंत में browser.close() कॉल किया गया है। इसी तरह, लिखने के बाद फ़ाइल हैंडल बंद करना सुनिश्चित करें।

• KeyboardInterrupt (Ctrl+C) को संभालें: हम मेन लूप में KeyboardInterrupt को ट्रैप कर सकते हैं और एक सुचारू शटडाउन शुरू कर सकते हैं – उदा., “रोका जा रहा है, सफाई की जा रही है…”, थ्रेड को बंद करें (शायद ThreadPoolExecutor.shutdown(wait=False) का उपयोग करके नए कार्य लॉन्च करना बंद करें), और ब्राउज़र बंद करें। यदि उपयोगकर्ता रद्द करता है तो यह अनाथ प्रक्रियाओं या लॉक की गई फ़ाइलों को रोकता है।

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

कोड गुणवत्ता: हम सर्वोत्तम कोडिंग प्रथाओं का पालन करेंगे:

• पठनीयता के लिए PEP8 शैली दिशानिर्देशों का पालन करें।

• सार्थक फ़ंक्शन और चर नामों का उपयोग करें।

• फ़ंक्शंस में उनके उद्देश्य और उपयोग की व्याख्या करने वाले डॉकस्ट्रिंग जोड़ें।

• फ़ंक्शन सिग्नेचर के लिए टाइप हिंट का उपयोग करें (पायथन 3 टाइप एनोटेशन) ताकि कोड को समझना आसान हो और टाइप की समस्याओं को जल्दी पकड़ा जा सके।

• कॉन्स्टेंट को मॉड्यूलराइज़ करें (जैसे हेडर पेलोड की सूची, अनदेखा करने के लिए स्थैतिक फ़ाइल एक्सटेंशन की सूची, आदि) शीर्ष पर या कॉन्फ़िग में, ताकि उन्हें आसानी से अपडेट किया जा सके। उदाहरण के लिए, HEADER_PAYLOADS = ["middleware:middleware:...","src/middleware:..."] आदि, एक स्थान पर परिभाषित।

• संभवतः कुछ हेल्पर फ़ंक्शंस के लिए यूनिट टेस्ट शामिल करें (यदि यह एक बड़ा प्रोजेक्ट होता, हालांकि एकल-स्क्रिप्ट टूल के लिए इसे छोड़ा जा सकता है; फिर भी, परीक्षण क्षमता को ध्यान में रखते हुए डिज़ाइन करना लाभदायक है)।

पेशेवर-ग्रेड संवर्द्धन: स्क्रिप्ट को अधिक मजबूत और उत्पादन-तैयार बनाने के लिए, हम आगे विचार कर सकते हैं:

• प्रमाणीकरण समर्थन: उपयोगकर्ता को कुकीज़ या क्रेडेंशियल प्रदान करने की अनुमति दें यदि वे साइट के एक प्रमाणित अनुभाग को स्कैन करना चाहते हैं (भले ही कमजोरी प्रमाणीकरण को बाइपास करने के बारे में है, ऐसे परिदृश्य हो सकते हैं जहां आपको कुछ लिंक तक पहुंचने के लिए पहले लॉग इन करना होगा ताकि उन पर बाइपास का परीक्षण किया जा सके – हालांकि बाइपास संभवतः वैध प्रमाणीकरण के बिना काम करता है, लेकिन यह गहरे लिंक क्रॉल करने में मदद कर सकता है जो सार्वजनिक नहीं हैं)।

• कॉन्फ़िगरेशन फ़ाइल: इंटरैक्टिव इनपुट के बजाय (या इसके अतिरिक्त), कॉन्फ़िग फ़ाइल या पर्यावरण चर से विकल्प पढ़ने की अनुमति दें, जो स्कैनर के स्वचालित परिनियोजन के लिए उपयोगी है।

• आउटपुट प्रारूप: अन्य उपकरणों के साथ एकीकरण के लिए JSON या CSV जैसे कई प्रारूपों में आउटपुट प्रदान करें। उदाहरण के लिए, एक --json ध्वज परिणामों को मशीन-पठनीय JSON के रूप में डंप कर सकता है।

• मौजूदा ढाँचों के साथ एकीकृत करें: तर्क को एक बड़े स्कैनिंग ढाँचे में एकीकृत किया जा सकता है (उदाहरण के लिए, इसे OWASP ZAP के लिए एक मॉड्यूल में बदलना या संगत रिपोर्ट आउटपुट करके ProjectDiscovery के Nuclei के साथ एकीकृत करना)। कम से कम, सुनिश्चित करें कि स्क्रिप्ट का आउटपुट कमजोरी और प्रभावित URL को स्पष्ट रूप से पहचानता है ताकि इसका उपयोग रिपोर्ट में किया जा सके।

• समानांतर ब्राउज़र सत्र: यदि बहुत बड़े एप्लिकेशन को लक्षित कर रहे हैं, तो एक साथ अलग-अलग अनुभागों को क्रॉल करने के लिए समानांतर में कई ब्राउज़र संदर्भ लॉन्च करने पर विचार करें। Playwright कई संदर्भों को संभाल सकता है (प्रत्येक संदर्भ पृथक है, अलग ब्राउज़र प्रोफ़ाइलों के समान)​। यह उच्च संसाधन उपयोग की कीमत पर क्रॉलिंग को काफी गति दे सकता है।

• सुचारू गिरावट: यदि Playwright विफल होता है (जैसे पर्यावरण में डिस्प्ले की कमी या उचित स्थापना), तो स्क्रिप्ट एक सरल requests-आधारित क्रॉल पर वापस आ सकती है (जो कुछ लिंक मिस कर सकता है लेकिन कुछ न करने से बेहतर है)। यह उपकरण को विभिन्न वातावरणों में अधिक मजबूत बनाता है। इसी तरह, यदि सहमति बहुत अधिक सेट की गई है और समस्या पैदा करती है, तो उन्हें पकड़ें और उपयोगकर्ता को थ्रेड काउंट कम करने का सुझाव दें।

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

अंत में, यह डिज़ाइन वेब एप्लिकेशन में CVE-2025-29927 का पता लगाने के लिए एक व्यापक दृष्टिकोण प्रस्तुत करता है। यह गहन क्रॉलिंग के लिए हेडलेस ब्राउज़र, कुशल स्कैनिंग के लिए मल्टी-थ्रेडिंग और विश्वसनीयता के लिए मजबूत कोडिंग प्रथाओं का लाभ उठाता है। विशेष हेडर के साथ और बिना प्रतिक्रियाओं की तुलना करके, यह विश्वसनीय रूप से उन कमजोर एंडपॉइंट की पहचान कर सकता है जहाँ Next.js मिडलवेयर को बाइपास किया जा रहा है​। परिणाम एक पेशेवर-ग्रेड टूल है जो सुरक्षा इंजीनियरों और डेवलपर्स को उनके अनुप्रयोगों में इस महत्वपूर्ण कमजोरी को तेजी से ढूंढने और संबोधित करने में मदद करता है।