Dois-je nettoyer le balisage HTML d’un CMS hébergé ?

Question

J'envisage de démarrer un service hébergé de type CMS pour les clients.

Dans ce cas, le client devrait saisir un texte qui serait transmis à toute personne venant visiter son site.Je prévois d'utiliser Markdown, éventuellement en combinaison avec WMD (l'aperçu en direct que SO utilise) pour les gros blocs de texte.

Maintenant, devrais-je nettoyer leur entrée pour le HTML ?Étant donné qu'il n'y aurait qu'une poignée de personnes qui éditeraient leur « CMS », tous des clients payants, devrais-je supprimer le mauvais code HTML ou devrais-je simplement les laisser se déchaîner ?Après tout, c'est leur « site »

Modifier: La principale raison pour laquelle je le ferais est de les laisser utiliser leur propre javascript, d'avoir leurs propres CSS et divs, etc. pour la sortie.

Answer 1

Pourquoi ne pas ne pas assainir l'entrée?

Si vous ne le faites pas, vous invitez la catastrophe - à votre client, à vous-même ou aux deux.

Answer 2

Votre question demande :

"Modifier:La principale raison pour laquelle je le ferais est de les laisser utiliser leur propre javascript, et d'avoir leurs propres CSS et divs et ainsi de suite pour la sortie".

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

Désormais, certains sites Web permettent aux utilisateurs de fournir du JavaScript et atténuent les risques de deux manières :

1. Hébergez le CMS de l'utilisateur individuel sous un domaine différent.Blogger et Tumblr (par ex.mon blog.blogspot.com contre.blogger.com) faites cela pour empêcher les modèles de l'utilisateur de voler les cookies d'autres utilisateurs.Vous devez savoir ce que vous faites et ne jamais héberger le contenu utilisateur sous le domaine racine.
2. Si le contenu utilisateur n’est jamais partagé entre utilisateurs, le script fourni par les utilisateurs malveillants n’a pas d’importance.Cependant, les CMS sont axés sur le partage, donc cela ne s'applique probablement pas ici.

Il existe certains filtres de liste noire qui peuvent fonctionner, 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.La liste noire est un moyen infaillible d’avoir des problèmes à la fois de sécurité et de fonctionnement.

Lorsque vous traitez des données utilisateur, traitez-les toujours comme non fiables.Si vous ne traitez pas ce problème dès le 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 empêcher XSS sans déranger vos utilisateurs.

Answer 3

Vous protégeriez également les employés mécontents, les attaques de clients ou tout autre type de comportement idiot.

Vous devez toujours procéder à une désinfection, quels que soient les utilisateurs ou les spectateurs.

Answer 4

Au moins analyser leur entrée et autoriser uniquement un certain "coffre-fort" sous-ensemble de balises HTML.

Answer 5

Je pense que vous devriez toujours désinfecter l’entrée. La plupart des gens utilisent un CMS car ils ne veulent pas créer leur propre site Web et souhaitent accéder facilement à la modification de leurs pages. Il est probable que ces utilisateurs n'essaieront pas de mettre un texte purifié, mais en protégeant leur contenu, vous protégez leurs utilisateurs.