flawopen.com/JavaScript में XSS/dangerouslySetInnerHTML

क्या React का dangerouslySetInnerHTML सुरक्षित है?

संदर्भ पृष्ठ

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

सामान्य JSX को लेबल प्रिंटर समझें: टेक्स्ट, टेक्स्ट ही रहता है। dangerouslySetInnerHTML एक ऐसी मशीन पर स्विच करता है जो स्ट्रिंग को HTML के रूप में पार्स करती है। यदि उसमें हमलावर के नियंत्रण वाली सामग्री हो, तो ब्राउज़र उसे सक्रिय markup मान सकता है। इस sink का उपयोग केवल ऐसे HTML के लिए करें जिसे स्पष्ट रूप से भरोसेमंद माना गया हो या ठीक उसी HTML context के लिए sanitize किया गया हो।

सामान्य JSX को इसकी आवश्यकता क्यों नहीं

जोखिम — बिना जाँचा HTML

function Comment({ html }) {
  return <p dangerouslySetInnerHTML=
    {{ __html: html }} />;
}

सुरक्षित — सामान्य JSX interpolation

function Comment({ text }) {
  return <p>{text}</p>;
}

dangerouslySetInnerHTML का उपयोग कब उचित है?

इसे तभी उपयोग करें जब उत्पाद को ऐसा सीमित rich-text format बनाए रखना हो जिसे सामान्य React children से व्यक्त नहीं किया जा सकता। CMS, editor या Markdown renderer अपने-आप भरोसेमंद नहीं होते: संग्रहित सामग्री और renderer का output भी अविश्वसनीय markup रख सकता है। अनुमत elements और attributes तय करें, DOMPurify जैसी maintained library से sanitize करें, और परिणाम को सीधे इस sink में दें।

सही तरीके से उपयोग

rendering boundary पर sanitize करें

dangerouslySetInnerHTML में मान देने से ठीक पहले DOMPurify जैसी maintained library से sanitize करें। HTML sanitizer के रूप में regular expressions का उपयोग न करें। Sanitized string को बाद में बदलने से बचें; आगे का परिवर्तन सुरक्षा गारंटी को अमान्य कर सकता है। Sanitizer और उसके parsing environment को अपडेट रखें।

अनुमत markup सीमित करें

केवल ज्ञात tags को रोकने वाली blocklist अधूरी है: जोखिम attributes, URL वाले fields, namespaces और parser के व्यवहार से भी आ सकता है। सुविधा के लिए आवश्यक कम-से-कम elements और attributes की allowlist बनाएँ और sanitizer को उसी नीति के अनुसार configure करें। Links और अन्य URL attributes को उत्पाद द्वारा अनुमत destinations के अनुसार अलग से जाँचें।

अपने code की जाँच

grep -rn "dangerouslySetInnerHTML" --include="*.jsx" --include="*.tsx" .

हर परिणाम के लिए मान के स्रोत और सभी transformations का पता लगाएँ। User input, imported content और संग्रहीत rich text को अविश्वसनीय मानें; पुष्टि करें कि sanitizer policy output context के अनुरूप है और बाद का कोई चरण sanitized परिणाम को नहीं बदलता।

अक्सर पूछे जाने वाले प्रश्न

क्या Markdown rendering अपने-आप सुरक्षित है?

यह renderer और उसकी configuration पर निर्भर करता है। जाँचें कि raw HTML स्वीकार होता है या नहीं और output sanitize होता है या नहीं; केवल Markdown conversion HTML को सुरक्षित नहीं बनाता।

क्या यह Vue के v-html पर भी लागू होता है?

हाँ। v-html भी framework की सामान्य text interpolation के बिना HTML को browser तक पहुँचाता है। इसे HTML sink मानें और उचित policy के अनुसार अविश्वसनीय सामग्री sanitize करें।

संदर्भ

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