AD

वेबसाइट सिक्योरिटी लैब: Reflected XSS वल्नेरेबिलिटी को प्रैक्टिकली कैसे ढूंढें और फिक्स करें

The Jayhooo Infotech 9/25/2026 02:55:00 PM
वेबसाइट सिक्योरिटी लैब: Reflected XSS वल्नेरेबिलिटी को प्रैक्टिकली कैसे ढूंढें और फिक्स करें

वेबसाइट सिक्योरिटी और एथिकल हैकिंग की शुरुआत

वेब एप्लिकेशन सिक्योरिटी (Web Application Security) की दुनिया में कदम रखते ही आपको कई तरह की कमजोरियों (Vulnerabilities) के बारे में सुनने को मिलता है। इनमें से सबसे चर्चित और खतरनाक कमजोरी है Cross-Site Scripting (XSS)। OWASP (Open Web Application Security Project) की टॉप 10 सूची में XSS हमेशा से एक बड़ा खतरा बनी रही है।

इस ट्यूटोरियल में, हम केवल थ्योरी की बात नहीं करेंगे। हम अपने कंप्यूटर पर एक सुरक्षित Local Security Lab बनाएंगे, उसमें एक कमजोर (Vulnerable) वेब पेज तैयार करेंगे, उस पर XSS अटैक परफॉर्म करेंगे और फिर सीखेंगे कि एक डेवलपर के रूप में इसे कैसे ठीक (Patch) किया जाता है।

Reflected XSS क्या होता है?

जब कोई वेबसाइट यूजर द्वारा इनपुट किए गए डेटा को बिना किसी सुरक्षा जांच (Sanitization या Encoding) के सीधे यूजर के ब्राउज़र पर वापस भेज (Reflect कर) देती है, तो उसे Reflected XSS कहा जाता है।

मान लीजिए आप किसी वेबसाइट पर कुछ सर्च करते हैं और वह वेबसाइट दिखाती है: 'You searched for: [Your Query]'। यदि वेबसाइट आपके सर्च किए गए शब्द को बिना फिल्टर किए HTML पेज में डाल देती है, तो एक अटैकर वहां साधारण टेक्स्ट की जगह हानिकारक जावास्क्रिप्ट (JavaScript) कोड लिख सकता है। ब्राउज़र इस कोड को वेबसाइट का ही हिस्सा मानकर रन कर देता है।

कदम 1: अपनी खुद की Vulnerable Lab सेट करें

इस प्रैक्टिकल को करने के लिए आपको किसी लाइव वेबसाइट को नुकसान पहुंचाने की जरूरत नहीं है। हम अपने सिस्टम पर ही एक HTML फ़ाइल बनाएंगे।

अपने कंप्यूटर पर Notepad या कोई भी टेक्स्ट एडिटर खोलें और नीचे दिए गए कोड को कॉपी करके xss_lab.html नाम से सेव करें:

<!DOCTYPE html>
<html>
<head>
    <title>Security Test Lab - XSS</title>
    <style>
        body { font-family: Arial, sans-serif; margin: 50px; background-color: #f4f4f9; }
        .container { background: white; padding: 30px; border-radius: 8px; box-shadow: 0px 0px 10px rgba(0,0,0,0.1); }
        input[type='text'] { width: 80%; padding: 10px; margin-right: 10px; }
        button { padding: 10px 20px; cursor: pointer; }
        #result { margin-top: 20px; font-weight: bold; color: #333; }
    </style>
</head>
<body>

<div class='container'>
    <h2>Custom Search Engine (Demo)</h2>
    <p>सर्च बॉक्स में कुछ भी टाइप करें और देखें कि वह कैसे रिफ्लेक्ट होता है:</p>
    
    <input type='text' id='userInput' placeholder='यहाँ टाइप करें...'>
    <button onclick='displaySearch()'>सर्च करें</button>
    
    <div id='result'></div>
</div>

<script>
    function displaySearch() {
        var input = document.getElementById('userInput').value;
        // सुरक्षा की कमी (Vulnerable Line):
        document.getElementById('result').innerHTML = 'आपका सर्च रिज़ल्ट: ' + input;
    }
</script>

</body>
</html>

अब इस xss_lab.html फ़ाइल पर डबल-क्लिक करके इसे अपने क्रोम (Chrome) या फ़ायरफ़ॉक्स (Firefox) ब्राउज़र में खोलें।

कदम 2: कमजोरी की पहचान करना (Testing the Input)

लैब खुलने के बाद, आइए पहले सामान्य व्यवहार की जांच करें:

  • सर्च बॉक्स में Hello World लिखें और 'सर्च करें' बटन पर क्लिक करें।
  • आपको स्क्रीन पर दिखेगा: आपका सर्च रिज़ल्ट: Hello World। यह सामान्य रूप से काम कर रहा है।

अब, हम यह टेस्ट करेंगे कि क्या यह इनपुट बॉक्स HTML और जावास्क्रिप्ट को स्वीकार कर रहा है। सर्च बॉक्स में यह साधारण HTML टैग डालें:

<u>My Underlined Text</u>

यदि स्क्रीन पर लिखा हुआ टेक्स्ट अंडरलाइन होकर आता है, तो इसका मतलब है कि ब्राउज़र इनपुट को साधारण टेक्स्ट नहीं मान रहा है, बल्कि उसे HTML कोड की तरह रेंडर कर रहा है। यह इस बात का संकेत है कि वेबसाइट वल्नेरेबल हो सकती है।

कदम 3: JavaScript Payload इंजेक्ट करना (The Exploit)

आमतौर पर, आधुनिक ब्राउज़र सीधे <script> टैग को innerHTML के जरिए चलने से रोकते हैं। इसलिए, प्रोफेशनल पेनिट्रेशन टेस्टर्स (Penetration Testers) वैकल्पिक पेलोड (Alternative Payloads) का उपयोग करते हैं जो बिना स्क्रिप्ट टैग के भी रन हो सकते हैं।

सर्च बॉक्स में नीचे दिया गया पेलोड कॉपी करके पेस्ट करें और सर्च बटन दबाएं:

<img src='invalid-image.jpg' onerror='alert("XSS Vulnerability Detected!")'>

यह पेलोड कैसे काम करता है?

  1. हमने एक इमेज टैग (<img>) का इस्तेमाल किया और उसके सोर्स (src) में एक ऐसी इमेज का नाम लिखा जो मौजूद नहीं है (invalid-image.jpg)।
  2. चूंकि इमेज लोड नहीं हो पाएगी, इसलिए ब्राउज़र का onerror इवेंट एक्टिवेट हो जाएगा।
  3. onerror के अंदर हमने जावास्क्रिप्ट का alert() फंक्शन लिखा है, जो तुरंत रन हो जाएगा और स्क्रीन पर एक पॉप-अप बॉक्स दिखाई देगा।

जैसे ही आप सर्च पर क्लिक करेंगे, आपके ब्राउज़र पर एक पॉप-अप अलर्ट दिखाई देगा जिसमें लिखा होगा: "XSS Vulnerability Detected!"। बधाई हो, आपने सफलतापूर्वक अपनी पहली XSS कमजोरी ढूंढ ली और उसे एक्सप्लोइट किया!

XSS के खतरे: यह क्यों खतरनाक है?

आप सोच सकते हैं कि सिर्फ एक अलर्ट बॉक्स दिखने से क्या नुकसान हो सकता है? लेकिन एक वास्तविक हमले में, अटैकर इस अलर्ट की जगह एक खतरनाक कोड लिख सकता है जो निम्नलिखित नुकसान पहुंचा सकता है:

  • कुकी स्टीलिंग (Cookie Stealing): अटैकर document.cookie का उपयोग करके आपके एक्टिव सेशन की कुकीज चुरा सकता है और आपके अकाउंट में बिना पासवर्ड के लॉगिन कर सकता है।
  • वेबसाइट डिफेसमेंट (Defacement): वेबसाइट के लुक और कंटेंट को पूरी तरह बदला जा सकता है।
  • रीडायरेक्शन (Redirection): यूजर को असली वेबसाइट से हटाकर किसी नकली/फिशिंग (Phishing) वेबसाइट पर भेजा जा सकता है।

कदम 4: कमजोरी को ठीक कैसे करें? (The Patch)

एक एथिकल हैकर का काम केवल कमजोरी ढूंढना नहीं, बल्कि उसे ठीक करना भी है। इस कोड में कमजोरी की मुख्य वजह जावास्क्रिप्ट का innerHTML प्रॉपर्टी का इस्तेमाल करना था, जो यूजर के इनपुट को सीधे HTML कोड के रूप में प्रोसेस करता है।

इसे ठीक करने के लिए, हमें इनपुट को 'टेक्स्ट' के रूप में ट्रीट करना चाहिए न कि 'कोड' के रूप में।

अपने कोड में नीचे दी गई लाइन को ढूंढें:

document.getElementById('result').innerHTML = 'आपका सर्च रिज़ल्ट: ' + input;

और इसे बदलकर यह सुरक्षित कोड लिख दें:

document.getElementById('result').textContent = 'आपका सर्च रिज़ल्ट: ' + input;

बदलाव का कारण: textContent (या innerText) ब्राउज़र को निर्देश देता है कि इनपुट में मौजूद किसी भी HTML या स्क्रिप्ट टैग को केवल सादे टेक्स्ट की तरह दिखाया जाए, उसे रन न किया जाए।

अब फ़ाइल को दोबारा सेव करें, ब्राउज़र रिफ्रेश करें और फिर से वही इमेज पेलोड डालकर टेस्ट करें। इस बार कोई पॉप-अप नहीं आएगा, बल्कि पूरा कोड स्क्रीन पर सुरक्षित रूप से प्रिंट हो जाएगा।

डेवलपर्स के लिए क्विक सुरक्षा चेकलिस्ट

  • इनपुट वैलिडेशन (Input Validation): हमेशा तय करें कि यूजर केवल वही डेटा इनपुट कर सके जिसकी उम्मीद है (जैसे फोन नंबर वाले फील्ड में केवल नंबर)।
  • आउटपुट एन्कोडिंग (Output Encoding): ब्राउज़र पर डेटा भेजने से पहले विशेष कैरेक्टर्स जैसे < को &lt; और > को &gt; में बदलें।
  • Content Security Policy (CSP): अपने सर्वर पर मजबूत CSP हेडर्स का उपयोग करें जो अनधिकृत जावास्क्रिप्ट को चलने से रोकते हैं।

अक्सर पूछे जाने वाले प्रश्न (FAQs)

1. क्या एथिकल हैकिंग सीखना गैर-कानूनी है?

नहीं, अपने खुद के सिस्टम या अनुमति प्राप्त वेबसाइट्स पर सुरक्षा खामियों की जांच करना पूरी तरह कानूनी और सुरक्षित है। बिना अनुमति के किसी अन्य वेबसाइट पर इसे आजमाना अपराध की श्रेणी में आता है।

2. Reflected XSS और Stored XSS में क्या अंतर है?

Reflected XSS में पेलोड तुरंत रिफ्लेक्ट होता है और डेटाबेस में सेव नहीं होता (यह केवल उस विशिष्ट लिंक या इनपुट पर काम करता है)। Stored XSS में पेलोड वेबसाइट के डेटाबेस में हमेशा के लिए सेव हो जाता है और जब भी कोई यूजर उस पेज पर जाता है, हमला सक्रिय हो जाता है।

3. क्या ब्राउज़र्स में XSS से बचने के लिए इन-बिल्ट सुरक्षा होती है?

हाँ, आधुनिक ब्राउज़र्स में 'XSS Auditor' या 'XSS Filter' होते हैं, लेकिन चालाक अटैकर्स अक्सर नए पेलोड बनाकर इन फिल्टर्स को बायपास कर लेते हैं। इसलिए डेवलपर स्तर पर सुरक्षा होना अनिवार्य है।

4. क्या वर्डप्रेस जैसी लोकप्रिय वेबसाइट्स भी XSS से प्रभावित हो सकती हैं?

हाँ, वर्डप्रेस के कोर में या उसके प्लगइन्स (Plugins) और थीम्स (Themes) में अक्सर XSS कमजोरियां पाई जाती हैं, जिन्हें समय-समय पर अपडेट्स के जरिए ठीक किया जाता है।

Tags

Post a Comment

0 Comments

You Can Contact on WhatsApp - 9509503477