flawopen.com/XSS in JavaScript/DOMPurify and innerHTML

क्या DOMPurify innerHTML को सुरक्षित बनाने के लिए पर्याप्त है?

संदर्भ गाइड

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

DOMPurify rich HTML के लिए मजबूत allow-list sanitizer है, बशर्ते उसका output बिना बदलाव सीधे HTML sink में जाए। इसे गोदाम के प्रवेश पर जाँचे गए पैकेज की तरह समझें: बाद में कोई प्रक्रिया उसे दोबारा पैक करे या दूसरे रास्ते से भेजे, तो पहली जाँच अंतिम सामग्री को नहीं ढकती। साधारण text के लिए textContent उपयोग करें और HTML parsing से बचें।

अभी जोखिम — पुराना sanitized data sink तक पहुँचता है

// पुरानी version/policy से save करते समय sanitize किया।
saveToDb(DOMPurify.sanitize(input));

// बाद में stored string पर बिना जाँच भरोसा किया गया।
el.innerHTML = fetchedFromDb;

ज़्यादा सुरक्षित — HTML sink के लिए sanitize करें

// Rich HTML चाहिए तो current library से sanitize करें
// HTML context में डालने से ठीक पहले।
el.innerHTML = DOMPurify.sanitize(untrustedHtml, {
  USE_PROFILES: { html: true },
});

// साधारण text को HTML की तरह parse न करें।
textNode.textContent = untrustedText;

सिर्फ save करते समय sanitize करना कमजोर तरीका क्यों है

Save के समय sanitize करना अपने आप में असुरक्षित नहीं, लेकिन पुराना data boundary बनाता है: sanitizer fix, policy change या छूटे हुए code path के बाद renderer पुराना output भरोसे से दिखा सकता है। Render करते समय current version और ठीक उसी sink की policy से फिर sanitize करें। Insert से पहले clean markup न बदलें और न दूसरी library को दें; post-processing sanitization को निष्प्रभावी कर सकती है।

Configuration और output context महत्त्वपूर्ण हैं

DOMPurify का default HTML, SVG और MathML की अनुमति देता है। केवल HTML चाहिए तो USE_PROFILES: { html: true } से profile सीमित करें। Review के बिना tags या attributes न बढ़ाएँ। DOMPurify CSS sanitizer नहीं है और हर external resource request नहीं रोकता; output केवल HTML context में रखें, JavaScript, attribute, XML, SVG या CSS में दोबारा उपयोग न करें।

Trusted Types और server-side rendering

समर्थित browsers में Content Security Policy से Trusted Types लागू करें ताकि approved policy से गुज़रे बिना HTML sinks को strings न दी जा सकें। DOMPurify TrustedHTML दे सकता है; इससे गलत sink assignment घटता है, लेकिन खराब configuration या post-processing ठीक नहीं होती। Server पर DOMPurify DOM implementation पर निर्भर है: jsdom को updated रखें और security-sensitive sanitization में happy-dom के साथ न चलाएँ।

Production checklist

✓साधारण text के लिए textContent लें। DOMPurify तभी लें जब product को सीमित rich HTML दिखाना हो।
✓अंतिम HTML sink पर current DOMPurify और reviewed न्यूनतम allow-list से sanitize करें; बाद में परिणाम न बदलें।
✓Output को HTML context में ही रखें। उसे JavaScript, CSS, attribute, XML, SVG या दूसरे parser context में न reuse करें।
✓Persistent setConfig(), hooks, ADD_TAGS/ADD_ATTR, server DOM versions और Trusted Types policy/CSP को साथ review करें।

HTML injection sinks खोजें

rg -n -g '*.{js,ts,jsx,tsx}' '(innerHTML|outerHTML|insertAdjacentHTML|document\.write|dangerouslySetInnerHTML)' .

हर match में untrusted data को sink तक trace करें, insertion से ठीक पहले sanitization जाँचें और बाद का code markup बदलता तो नहीं यह देखें।

स्रोत और संदर्भ

यह भी देखें क्रॉस-साइट स्क्रिप्टिंग (XSS, CWE-79): यह कैसे काम करती है और हर भाषा में इसे कैसे रोकें — flawopen.com क्या Markdown रेंडरिंग XSS से सुरक्षित है? क्या Svelte डिफ़ॉल्ट रूप से XSS से सुरक्षित है? क्या SVG upload में XSS का जोखिम है? Vue v-html से XSS का जोखिम WKWebView: अविश्वसनीय HTML सुरक्षित? Reflected, stored और DOM-based XSS में क्या अंतर है?