Devrais-je désinfecter le balisage HTML pour un CMS hébergé?

Question

Je cherche à démarrer un service de type CMS hébergé pour les clients. Comme il le ferait, il faudrait que le client saisisse du texte qui serait servi à quiconque viendrait visiter son site. Je prévois d'utiliser Markdown, éventuellement en combinaison avec WMD (l'aperçu de démarquage en direct que SO utilise) pour les gros blocs de texte. Maintenant, devrais-je désinfecter leur entrée pour le HTML? Étant donné qu'il n'y aurait qu'une poignée de personnes qui éditeraient leur «CMS», tous les clients payants, devrais-je éliminer le mauvais HTML, ou devrais-je juste les laisser courir? Après tout, il est leur « site »

Edit: La principale raison pour laquelle je le ferais est de les laisser utiliser leur propre javascript, et ont leur propre css et divs et ce qui ne pour la sortie

Answer 1

Pourquoi ne pas vous aseptisez l'entrée? Si vous ne le faites pas, vous invitez la calamité - à votre client ou à vous-même ou aux deux.

Answer 2

Au moins analyser leur entrée et permettre seulement un certain sous-ensemble "sûr" de balises HTML.

Answer 3

Je pense que vous devriez toujours désinfecter l'entrée. La plupart des gens utilisent un CMS parce qu'ils ne veulent pas créer leur propre site web à partir de zéro et ils veulent un accès facile pour éditer leurs pages. Ces utilisateurs n'essaieront probablement pas de mettre du texte qui serait nettoyé, mais en protégeant contre cela, vous protégez leurs utilisateurs.

Answer 4

Vous protégeriez également les employés mécontents, les attaques croisées entre clients ou tout autre comportement idiot.

Vous devriez toujours désinfecter, peu importe les utilisateurs ou les spectateurs.

Answer 5

Votre question demande:

« Edit: La principale raison pour laquelle je le ferais est de les laisser utiliser leur propre javascript, et ont leur propre css et divs et ce non pour la sortie ».

Si vous autorisez les utilisateurs à fournir du code JavaScript arbitraire, la désinfection des données n'en vaut pas la peine. La définition de Cross-Site Scripting (XSS) est fondamentalement «les utilisateurs peuvent fournir JavaScript et certains utilisateurs sont mauvais».

Maintenant, certains sites ne permettent aux utilisateurs de fournir JavaScript et ils atténuent le risque dans l'une des deux façons suivantes:

1. hôte du CMS de chaque utilisateur de ce sous un autre domaine. Blogger et Tumblr (par exemple, blogspot .com vs blogger.com) font cela pour empêcher les modèles de l'utilisateur de voler les cookies des autres utilisateurs. Vous devez savoir ce que vous faites et n'hébergez jamais le contenu de l'utilisateur sous le domaine racine.
2. Si le contenu utilisateur n'est jamais partagé entre les utilisateurs, peu importe le script fourni par les utilisateurs malveillants. Cependant, CMS sont sur le partage afin que cela ne s'applique probablement pas ici

Il y a certains filtres Blacklist là-bas qui peuvent travailler, mais ils ne fonctionnent que aujourd'hui. Les spécifications HTML et les navigateurs changent régulièrement, ce qui rend les filtres presque impossibles à maintenir. Blacklisting est un moyen sûr d'avoir à la fois des problèmes de sécurité et de fonctionnement.

Lorsque vous traitez des données utilisateur, traitez-les toujours comme non fiables. Si vous ne le faites pas au début du produit et que vos scénarios changent, il est presque impossible de revenir en arrière et de trouver tous les points XSS ou de modifier le produit pour éviter XSS sans déranger vos utilisateurs.