HTMX n’est pas bien compatible avec la CSP (Content Security Policy)

• HTMX est un framework JavaScript qui permet de remplacer des éléments du DOM par des données dynamiques via des requêtes AJAX
• Comme HTMX ajoute des comportements dynamiques aux pages à l’aide de balises HTML ordinaires avec des attributs personnalisés, il est difficile d’apporter une sécurité supplémentaire contre les attaques de cross-site scripting (XSS)
• En général, une Content Security Policy (CSP) permet de restreindre le JavaScript qui peut être exécuté
• Il est difficile de configurer une CSP qui continue de laisser fonctionner HTMX tout en protégeant contre le cross-site scripting

Chargement de fragments malveillants

• L’une des méthodes d’injection avec HTMX consiste à effectuer une requête vers un hôte malveillant
• HTMX récupère des fragments HTML pouvant contenir du JavaScript, puis les insère dans la page
• Cela peut être utilisé pour déclencher des requêtes vers des domaines autres que celui de l’application web et charger des scripts malveillants

eval non sécurisé

• HTMX génère et exécute du code dynamiquement
• Les fonctionnalités HTMX suivantes le font : filtres de déclenchement, attributs hx-on, hx-vals ou hx-headers avec les préfixes js:/javascript:
• Pour que ces fonctionnalités marchent, l’application doit autoriser l’évaluation dynamique de code via l’option CSP unsafe-eval
• Mais autoriser unsafe-eval permet aussi d’injecter immédiatement du JavaScript en utilisant les fonctionnalités de HTMX

Désactiver HTMX avec hx-disable

• L’attribut hx-disable permet de désactiver les fonctionnalités de HTMX sur une partie de la page
• La documentation affirme que cela peut apporter une sécurité supplémentaire
• Mais il est facile de le contourner : il suffit de fermer la balise div avec `

et d’insérer la charge utile en dehors de l’élément qui possède l’attributhx-disable`

Nonce pour les scripts inline

• Utiliser un nonce dans la CSP est le moyen le plus sûr d’empêcher l’injection de scripts
• L’application génère un nonce aléatoire et l’ajoute à tous les scripts qui font partie de l’application
• Les scripts injectés par un attaquant n’ont pas le bon nonce et ne s’exécutent donc pas
• HTMX dispose d’une fonctionnalité qui ajoute automatiquement le bon nonce aux scripts inline qu’il récupère
• C’est pratique, mais cela casse complètement le modèle de sécurité d’une CSP basée sur des nonces
• En ajoutant le bon nonce à tous les scripts trouvés, HTMX compromet totalement la sécurité apportée par le nonce
• L’ajout automatique de nonce se fait via le paramètre htmx.config.inlineScriptNonce

Balises meta de configuration

• HTMX propose plusieurs options de configuration via la balise ``
• Lors d’une attaque XSS, il est possible de modifier la configuration de HTMX en injectant la bonne balise ``
• Par exemple, il a été mentionné plus haut que l’attribut hx-disable désactive le traitement HTMX
• Mais on peut changer le nom de cet attribut dans la configuration
• En le remplaçant par autre chose que hx-disable, il devient possible de désactiver le fonctionnement de hx-disable

Conclusion

• Utiliser HTMX sur un site augmente fortement la surface d’attaque liée à l’injection HTML
• Une Content Security Policy peut limiter les risques de XSS, mais il est impossible d’assurer une protection contre l’injection tout en conservant toutes les fonctionnalités de HTMX

[galadbran]

On pourrait s’attendre à voir une réponse à cet article ou au moins des explications sur une manière sûre de l’utiliser...

[xguru]

Sortie de Htmx 2.0.0
htmx - des outils puissants pour HTML