Protéger vos utilisateurs Contre les attaques XSS basées sur DOM

Protéger Vos utilisateurs Contre les attaques XSS basées Sur DOM

Le script intersite (XSS) est l’un des sites Web d’attaque wayshackers les plus courants. Les vulnérabilités XSS permettent à un utilisateur malveillant d’exécuter des morceaux arbitraires de JavaScript lorsque d’autres utilisateurs visitent votre site.

XSS est la vulnérabilité de sécurité la plus fréquemment signalée publiquement et fait partie de la boîte à outils de chaque pirate.

Risques

Prévalence Rare

Exploitabilité Facile

Impact Nocif

Les attaques XSS basées sur DOM présentent tous les risques associés aux autres types d’attaques XSS, avec le bonus ajouté qu’elles sont impossibles à détecter côté serveur.Toute page qui utilise des fragments d’URI est potentiellement à risque d’attaques XSS.

Protection

La protection contre les attaques XSS basées sur DOM consiste à vérifier que yourJavaScript n’interprète pas les fragments d’URI de manière dangereuse. Il existe un certain nombre de façons d’assurer cela.

Utilisez un framework JavaScript

Des frameworks comme AngularJS et React utilisent des modèles qui font de la construction de HTML ad hoc une action explicite (et rare). Cela poussera votre équipe de développement vers les meilleures pratiques et facilitera la détection des opérations dangereuses.

AngularJS

Dans Angular, tout contenu dynamique écrit entre crochets sera automatiquement échappé, ce qui suit est donc sûr:

 <div>{{dynamicContent}}</div>

Méfiez-vous de tout code qui lie du contenu dynamique aux attributs innerHTML, car ceux-ci ne seront pas échappés automatiquement:

 <div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>
React

Dans React, tout contenu dynamique écrit entre crochets sera automatiquement échappé, ce qui suit est donc sûr:

render() { return <div>{dynamicContent}</div>}

React vous permet d’écrire du HTML brut en liant le contenu à la propriété dangerouslySetInnerHTML, qui est nommée pour vous rappeler le risque de sécurité ! Méfiez-vous de tout code qui ressemble à ce qui suit:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
Auditez soigneusement votre Code

Parfois, un framework JavaScript complet est trop lourd pour votre site.In dans ce cas, vous devrez effectuer régulièrement des examens du code pour repérer les localisationscette référence window.location.hash. Envisagez de proposer des normes de codage convenues sur la façon dont les fragments d’URI doivent être écrits et interprétés, et centralisez cette logique dans une bibliothèque centrale.

Si vous utilisez jQuery, vérifiez soigneusement tout code qui utilise la fonction html(...). Si vous construisez du code HTML brut côté client à l’arrière d’une entrée non approuvée, vous pouvez avoir un problème, que l’entrée provienne d’un fragment d’URI ou non. Utilisez la fonction text(...) dans la mesure du possible.

Si vous utilisez directement les API DOM natives, évitez d’utiliser les propriétés et fonctions suivantes:

  • innerHTML
  • outerHTML
  • document.write

Au lieu de cela, définissez le contenu du texte dans les balises dans la mesure du possible:

  • textContent
Analysez soigneusement JSON

N’évaluez pas JSON pour le convertir en objets JavaScript natifs – par exemple, en utilisant la fonction eval(...). Utilisez plutôt JSON.parse(...).

Détecter le Code dangereux À l’aide d’outils de développement

La Suite Burp, produite par la société de sécurité PortSwigger, peut être utilisée pour détecter les vulnérabilités basées sur DOM.

N’Utilisez pas Du Tout De Fragments D’URI !

Le code le plus sécurisé est celui qui n’existe pas. Si vous n’avez pas besoin d’utiliser des fragments d’URI, alors ne le faites pas! Écrivez un test unitaire pour analyser votre JavaScript à la recherche des mentions window.location.hash, et faites-le échouer si le modèle est trouvé. Lorsqu’il est nécessaire d’utiliser des fragments d’URI, vous pouvez discuter de la façon d’assurer leur utilisation en toute sécurité.

Implémenter une Politique de sécurité du contenu

Les navigateurs modernes prennent en charge les politiques de sécurité du Contentqui permettent à l’auteur d’une page Web de contrôler à partir de laquelle JavaScript (et d’autres ressources) peut être chargé et exécuté. Les attaques XSS reposent sur le fait que l’attaquant peut exécuter des scripts malveillants sur la page Web d’un utilisateur – soit en injectant des balises <script> en ligne quelque part dans la balise <html> d’une page, soit en incitant le navigateur à charger le JavaScript à partir d’un domaine tiers malveillant.

En définissant une stratégie de sécurité du contenu dans l’en-tête de réponse, vous pouvez demander au navigateur de ne jamais exécuter JavaScript en ligne et de verrouiller les domaines pouvant héberger JavaScript pour une page:

Politique de sécurité du contenu: scénario – src’ self’ https://apis.google.com

En mettant sur liste blanche les URI à partir desquels les scripts peuvent être chargés, vous indiquez implicitement que JavaScript en ligne n’est pas autorisé.

La stratégie de sécurité du contenu peut également être définie dans une balise <meta> dans l’élément <head> de la page:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

Cette approche protégera vos utilisateurs très efficacement! Cependant, cela peut prendre une quantité considérable de discipline pour préparer votre site à un tel en-tête.Les balises de scripts en ligne sont considérées comme de mauvaises pratiques dans le développement Web moderne – le mélange de contenu et de code rend les applications Web difficiles à maintenir – mais sont courantes dans les sites anciens et hérités.

Pour migrer progressivement des scripts en ligne, pensez à utiliser la violation ofCSP de makings Reports.By en ajoutant une directive report-uri dans l’en-tête de votre stratégie, le navigateur vous informera de toute violation de stratégie, plutôt que d’empêcher l’exécution de JavaScript en ligne:

Content-Security-Policy-Report-Only : script-src ‘self’; rapport – uri http://example.com/csr-reports

Cela vous rassurera qu’il n’y a pas de scripts en ligne persistants, avant de les interdire purement et simplement.

Pour en savoir plus

  • Comment fonctionne le script intersite
  • Une introduction à la Politique de sécurité du contenu
  • CSP (Content Security Policy) sur le Réseau des développeurs Mozilla
  • Vulnérabilité de script intersite basée sur DOM
  • Explication de la Politique de sécurité du contenu
Script intersite

XSS Reflété

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.