flawopen.com/XSS/Markdown रेंडरिंग

क्या Markdown रेंडरिंग XSS से सुरक्षित है?

संदर्भ मार्गदर्शिका

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

Markdown से बने HTML को अविश्वसनीय सामग्री मानें। सिंटैक्स इसकी अनुमति देता है, इसलिए पार्सर कच्चे HTML को जस का तस रख सकता है; Markdown बदलने से आउटपुट साफ़ नहीं होता। पार्सर मार्कअप का अनुवादक है, सुरक्षा प्रहरी नहीं।

विश्वास की सीमा कहाँ है

CommonMark विनिर्देश के अनुसार टैग जैसा कच्चा HTML बिना एस्केप किए रेंडर होता है। वास्तविक व्यवहार पार्सर, उसके विकल्पों, प्लगइन और होस्ट फ्रेमवर्क पर निर्भर करता है। उदाहरण के लिए, Marked स्पष्ट करता है कि वह बनाया गया HTML साफ़ नहीं करता। Markdown सिंटैक्स इनपुट की सुरक्षा सिद्ध नहीं करता; सैनिटाइज़र को अंतिम HTML इंसर्शन स्थान सुरक्षित करना चाहिए।

सुरक्षित रेंडरिंग प्रक्रिया

असुरक्षित — बिना साफ़ किया आउटपुट डालना

const html = marked.parse(userMarkdown);
container.innerHTML = html; // पार्सर आउटपुट साफ़ नहीं है

सुरक्षित — HTML इंसर्शन से ठीक पहले साफ़ करें

import DOMPurify from "dompurify";

const html = marked.parse(userMarkdown);
container.innerHTML = DOMPurify.sanitize(html, {
  USE_PROFILES: { html: true }
});

उदाहरण DOMPurify का केवल-HTML प्रोफ़ाइल उपयोग करता है क्योंकि इस दृश्य में SVG या MathML की ज़रूरत नहीं है। उत्पाद के लिए आवश्यक न्यूनतम सुविधाएँ ही अनुमति दें। साफ़ किए गए मार्कअप को बदलें नहीं और डालने से पहले किसी अन्य HTML बदलने वाली लाइब्रेरी से न गुज़ारें; इससे सुरक्षा आश्वासन टूट सकता है। समृद्ध HTML आवश्यक न हो तो फ्रेमवर्क का सुरक्षित टेक्स्ट रेंडरिंग चुनें। Content Security Policy और Trusted Types अतिरिक्त सुरक्षा हैं, सैनिटाइज़ेशन का विकल्प नहीं।

प्रोडक्शन समीक्षा की जाँच-सूची

✓Markdown पार्सर का संस्करण स्थिर रखें और कच्चे HTML, प्लगइन तथा URL विकल्पों की समीक्षा करें।
✓अंतिम HTML इंसर्शन से ठीक पहले बनाए गए HTML को रखरखाव वाले allowlist सैनिटाइज़र से साफ़ करें।
✓अनुमत तत्वों, विशेषताओं और URL प्रोटोकॉल को आवश्यक सुविधाओं तक सीमित करें।
✓सैनिटाइज़ेशन के बाद मार्कअप न बदलें या दोबारा पार्स न करें; किसी ज़रूरी बदलाव के बाद फिर साफ़ करें।
✓पार्सर की सटीक सेटिंग और रेंडरिंग स्थान का परीक्षण करें तथा सैनिटाइज़र अपडेट रखें।

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

क्या कच्चा HTML बंद करने से Markdown सुरक्षित हो जाता है?

इससे इनपुट की एक सुविधा हटती है, लेकिन अकेले इससे सुरक्षा सिद्ध नहीं होती। लिंक, चित्र, एक्सटेंशन, बने HTML और इंसर्शन संदर्भ जाँचें; HTML में डालने से पहले आउटपुट साफ़ करें।

क्या साफ़ करने के बाद HTML बदल सकते हैं?

ऐसा न करें। बाद के बदलाव असुरक्षित मार्कअप जोड़ सकते हैं या सैनिटाइज़र के निर्णय निष्प्रभावी कर सकते हैं। पहले बदलाव करें और अंत में साफ़ करें।

क्या DOMPurify हर संदर्भ में किसी भी आउटपुट को सुरक्षित बनाता है?

नहीं। दस्तावेज़ित खतरा-मॉडल के अनुसार HTML अंशों के लिए इसका उपयोग करें, इसे अपडेट रखें, संकीर्ण नीति अपनाएँ और परिणाम को JavaScript या CSS स्ट्रिंग जैसे दूसरे संदर्भ में पुनः उपयोग न करें।

स्रोत

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