flawopen.com/XSS/XSS के प्रकार

Reflected, stored और DOM-based XSS में क्या अंतर है?

संदर्भ पृष्ठ

संक्षिप्त उत्तर

Reflected, stored और DOM-based XSS अविश्वसनीय data से browser के असुरक्षित context तक पहुँचने के अलग रास्ते बताते हैं। ये आपस में overlap कर सकते हैं: value का source, उसका persist होना, उसे render करने वाला code और प्रभावित user पहचानें।

तीन प्रकार

Reflected XSS — value request में होती है

Request की value context-appropriate encoding के बिना response में आती है और browser उसे markup या script की तरह समझता है। Attacker victim को तैयार link भेज सकता है, पर मूल दोष request data का असुरक्षित rendering है। Rendering sink पर output ठीक करें।

Stored XSS — value सहेजी जाती है

अविश्वसनीय content सहेजा जाता है और बाद में comment या profile field में अन्य users के लिए असुरक्षित रूप से render होता है। Content देखने वाला हर visitor उसी असुरक्षित context में पहुँच सकता है, जब तक stored value या rendering path ठीक न हो।

DOM-based XSS — client code data को असुरक्षित DOM sink तक भेजता है

Client-side JavaScript अविश्वसनीय source (जैसे location.hash, query parameter या server से मिली value) पढ़कर उसे innerHTML जैसे असुरक्षित DOM sink में लिखता है। Value server तक न पहुँचे, यह जरूरी नहीं; DOM-based XSS client-side source-to-sink path है और reflected/stored delivery से overlap कर सकता है। Client-side data flow ठीक करें।

सुधार के लिए यह अंतर क्यों मायने रखता है

XSS को rendering sink पर context-appropriate output encoding या सुरक्षित DOM API से ठीक करें। Reflected और stored XSS में अक्सर server rendering शामिल है, लेकिन client rendering भी असुरक्षित sink बना सकती है। DOM-based XSS के लिए text में innerHTML की जगह textContent उपयोग करें; rich HTML जरूरी हो तो स्पष्ट policy वाला maintained sanitizer लें। Server-side encoding client-side source-to-sink flows की समीक्षा का विकल्प नहीं है।

ये श्रेणियाँ एक-दूसरे से overlap कर सकती हैं

Reflected और stored यह बताते हैं कि input page तक कैसे पहुँचती है और क्या persist होती है। DOM-based client-side source-to-sink path बताता है। ये श्रेणियाँ एक-दूसरे को exclude नहीं करतीं: client code द्वारा persisted profile text को innerHTML में डालना stored और DOM-based दोनों XSS हो सकता है।

DOM-based XSS: असुरक्षित sink और केवल text rendering

असुरक्षित — untrusted text को HTML की तरह parse करना

const value = new URLSearchParams(location.search).get("q") ?? "";
target.innerHTML = value;

Text के लिए सुरक्षित — text के रूप में render करना

const value = new URLSearchParams(location.search).get("q") ?? "";
target.textContent = value;

संदर्भ

यह भी देखें क्रॉस-साइट स्क्रिप्टिंग (XSS, CWE-79): यह कैसे काम करती है और हर भाषा में इसे कैसे रोकें — flawopen.com Android addJavascriptInterface के सुरक्षा जोखिम Angular XSS सुरक्षा: सुरक्षित defaults और bypass APIs MIME sniffing XSS: Content-Type और nosniff CSP और output escaping: क्या दोनों चाहिए? क्या React का dangerouslySetInnerHTML सुरक्षित है? क्या innerHTML के लिए DOMPurify पर्याप्त है?