flawopen.com/XSS in Swift/loadHTMLString

Ist WKWebView.loadHTMLString unter iOS für nicht vertrauenswürdige Inhalte sicher?

Referenzseite

Kurzantwort

Nicht automatisch: WKWebView interpretiert den übergebenen String als HTML. Tags und skriptfähiges Markup bleiben aktiv, bis der Inhalt vertrauenswürdig ist oder kontextgerecht behandelt wird. Klartext und nutzergeliefertes Rich-HTML erfordern unterschiedliche Schutzmaßnahmen.

Sichere Verwendung

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)

Zusätzliches Risiko prüfen

Ein Nachrichtenhandler in der Seitenwelt eröffnet Seitenskripten einen Weg in den App-Code. `WKContentWorld` kann JavaScript-Umgebungen trennen, doch Seiten- und App-Skripte teilen weiterhin das DOM. Wenn nicht vertrauenswürdiges HTML und eine Bridge zusammenkommen, lege nur die unbedingt nötige Fähigkeit offen, prüfe Nachricht und Frame und autorisiere jeden Vorgang; verwechsle getrennte Welten nicht mit Autorisierung.

Was baseURL steuert

Apple beschreibt `baseURL` als Basis zum Auflösen relativer URLs im übergebenen HTML. Der Parameter bereinigt kein Markup und deaktiviert kein JavaScript der Seite. `nil` ist weder XSS-Schutz noch Sandbox-Einstellung; lege Ressourcen- und Navigationsregeln getrennt fest.

Für jede Grenze den passenden Schutz wählen

Für Klartext in einem HTML-Textknoten verwende einen Encoder für genau diesen Kontext, wie unten; nutze ihn nicht für Attribute, URLs, CSS oder JavaScript wieder. Für nutzergeliefertes Rich-HTML verwende einen gepflegten Sanitizer mit expliziten Positivlisten für Elemente, Attribute und URL-Schemata. Übergebe Werte mit `callAsyncJavaScript`-Argumenten an App-JavaScript, statt sie in Quelltext einzusetzen. Falls die Seite kein JavaScript braucht, kann `allowsContentJavaScript` Seitenskripte als zusätzliche Schutzschicht deaktivieren; korrekte Ausgabebehandlung ersetzt das nicht.

FAQ

Ist das veraltete UIWebView anders?

Nein: Es birgt dasselbe Risiko und bietet ebenfalls keine zusätzliche Bereinigung. Der Wechsel zu WKWebView modernisiert die Technik, behebt aber nicht automatisch das Sicherheitsproblem.

Verhindert `baseURL: nil` XSS?

Nein. Apple dokumentiert `baseURL` zum Auflösen relativer URLs. Es ist kein HTML-Sanitizer, Skriptschalter oder Sandbox-Versprechen.

Isoliert `WKContentWorld` das Seiten-DOM?

Nein. Es trennt JavaScript-Umgebungen, die sich aber das DOM teilen. Behandle DOM-Daten und Nachrichten als nicht vertrauenswürdig und autorisiere jede native Aktion separat.

Quellen

Siehe auch Cross-Site-Scripting (XSS, CWE-79): Funktionsweise und Schutz in jeder Sprache — flawopen.com Reflected, Stored und DOM-basiertes XSS: Wo liegt der Unterschied? Sicherheitsrisiken von addJavascriptInterface unter Android Angular-XSS-Schutz: sichere Standards und Bypass-APIs XSS durch MIME-Sniffing: Content-Type und nosniff CSP und Output-Escaping: Brauchst du beides? Ist dangerouslySetInnerHTML in React sicher?