FlawOpen

flawopen.com/XSS en Swift/loadHTMLString

WKWebView.loadHTMLString est-il sûr sur iOS avec du contenu non fiable ?

Page de référence
Réponse courte

Pas automatiquement : WKWebView interprète la chaîne reçue comme du HTML ; les balises et le balisage pouvant exécuter des scripts restent donc actifs tant que le contenu n’est pas fiable ou traité selon le bon contexte. Le texte brut et le HTML riche fourni par des utilisateurs nécessitent des contrôles différents.

Utilisation sûre

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)

Risque supplémentaire à vérifier

Un gestionnaire de messages dans le monde de la page donne à ses scripts un accès au code de l’app. `WKContentWorld` peut séparer les environnements JavaScript, mais les scripts de la page et de l’app partagent toujours le DOM. Si du HTML non fiable coexiste avec une passerelle, n’exposez que la capacité minimale, validez le message et son frame, puis autorisez chaque opération ; ne confondez pas séparation des mondes et autorisation.

Ce que contrôle baseURL

Apple décrit `baseURL` comme la base utilisée pour résoudre les URL relatives du HTML fourni. Ce paramètre n’assainit pas le balisage et ne désactive pas le JavaScript de la page. `nil` ne protège pas contre XSS et ne crée pas une sandbox ; définissez séparément la politique de ressources et de navigation.

Choisir un contrôle pour chaque frontière

Pour du texte brut dans un nœud de texte HTML, utilisez un encodeur propre à ce contexte, comme ci-dessous ; ne le réutilisez pas dans des attributs, URL, CSS ou JavaScript. Pour du HTML riche fourni par les utilisateurs, utilisez un assainisseur maintenu avec des listes explicites d’éléments, d’attributs et de schémas d’URL autorisés. Passez les valeurs au JavaScript de l’application avec les arguments de `callAsyncJavaScript`, sans les interpoler dans le code source. Si la page n’a pas besoin de JavaScript, `allowsContentJavaScript` peut désactiver les scripts de la page en défense supplémentaire ; cela ne remplace pas le traitement correct des sorties.

FAQ

L’ancien UIWebView est-il différent ?

Non : il présente le même risque et n’intègre pas non plus d’assainissement supplémentaire. Passer à WKWebView modernise la technologie, mais ne corrige pas la sécurité à lui seul.

`baseURL: nil` empêche-t-il XSS ?

Non. Apple documente `baseURL` pour résoudre les URL relatives. Ce n’est ni un assainisseur HTML, ni un interrupteur de scripts, ni une garantie de sandbox.

`WKContentWorld` isole-t-il le DOM de la page ?

Non. Il sépare les environnements JavaScript, qui partagent toutefois le DOM. Traitez les données du DOM et les messages comme non fiables et autorisez chaque opération native séparément.

Références

À voir aussi Cross-Site Scripting (XSS, CWE-79) : fonctionnement et prévention dans chaque langage — flawopen.com XSS réfléchi, stocké et DOM : quelles différences ? Risques de sécurité de addJavascriptInterface sur Android Angular : XSS, valeurs sûres et API de bypass XSS par MIME sniffing : Content-Type et nosniff CSP et échappement de sortie : faut-il les deux ? dangerouslySetInnerHTML est-il sûr dans React ?