FlawOpen

flawopen.com/Swift में XSS/loadHTMLString

क्या iOS का WKWebView.loadHTMLString अविश्वसनीय सामग्री के लिए सुरक्षित है?

संदर्भ पृष्ठ
संक्षिप्त उत्तर

अपने आप सुरक्षित नहीं होता: WKWebView दी गई string को HTML की तरह parse करता है, इसलिए tags और script चलाने वाली markup तब तक सक्रिय रहती है जब तक सामग्री भरोसेमंद न हो या सही context के लिए संभाली न गई हो। साधारण text और user-authored rich HTML के लिए अलग नियंत्रण चाहिए।

सुरक्षित उपयोग

RISKY
let html = "
\(untrustedText)
"
webView.loadHTMLString(html, baseURL: nil)
SAFER
func escapeHTMLText(_ value: String) -> String {
    value
        .replacingOccurrences(of: "&", with: "&")
        .replacingOccurrences(of: "<", with: "<")
        .replacingOccurrences(of: ">", with: ">")
        .replacingOccurrences(of: "\"", with: """)
        .replacingOccurrences(of: "'", with: "'")
}

let html = "
\(escapeHTMLText(untrustedText))
"
webView.loadHTMLString(html, baseURL: nil)

जाँचने योग्य अतिरिक्त जोखिम

Page-world message handler पेज स्क्रिप्ट को ऐप कोड तक रास्ता देता है। `WKContentWorld` JavaScript environments को अलग कर सकता है, लेकिन पेज और ऐप स्क्रिप्ट DOM साझा करते हैं। यदि untrusted HTML और bridge साथ हों, तो केवल न्यूनतम क्षमता expose करें, message और उसके frame को validate करें और हर operation को authorize करें; world separation को authorization न समझें।

baseURL क्या नियंत्रित करता है

Apple `baseURL` को दिए गए HTML में relative URL resolve करने के आधार के रूप में बताता है। यह markup को sanitize नहीं करता और पेज का JavaScript बंद नहीं करता। `nil` XSS या sandbox सुरक्षा नहीं है; resource और navigation नीति अलग से तय करें।

हर boundary के लिए सही नियंत्रण चुनें

HTML text node में साधारण text डालते समय उसी context के लिए encoder इस्तेमाल करें, जैसे नीचे दिया गया है; इसे attributes, URLs, CSS या JavaScript में दोबारा इस्तेमाल न करें। उपयोगकर्ता-लिखित rich HTML के लिए maintained sanitizer लें और elements, attributes तथा URL schemes की स्पष्ट allowlist रखें। App JavaScript को values `callAsyncJavaScript` arguments से दें, source में interpolate न करें। `WKContentWorld` JavaScript environments अलग करता है, लेकिन DOM साझा रहता है; इससे native actions की अनुमति नहीं मिलती। Bridge को सीमित रखें और हर message तथा operation validate करें। यदि पेज को JavaScript की जरूरत न हो, तो `allowsContentJavaScript` अतिरिक्त सुरक्षा के रूप में page scripts बंद कर सकता है; यह सही output handling का विकल्प नहीं है।

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

क्या पुराना UIWebView अलग है?

नहीं। उसमें भी यही जोखिम है और कोई अतिरिक्त अंतर्निहित सैनिटाइज़ेशन नहीं है। WKWebView पर जाना तकनीक को आधुनिक बनाता है, लेकिन अपने आप सुरक्षा समस्या हल नहीं करता।

क्या `baseURL: nil` XSS रोकता है?

नहीं। Apple `baseURL` को relative URL resolve करने के लिए बताता है। यह HTML sanitizer, script switch या sandbox की गारंटी नहीं है।

क्या `WKContentWorld` page DOM को isolate करता है?

नहीं। यह JavaScript environments अलग करता है, लेकिन वे DOM साझा करते हैं। DOM data और messages को अविश्वसनीय मानें और हर native operation को अलग से authorize करें।

संदर्भ

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