Que faites-vous lorsqu'un client requiert la modification de texte enrichi sur son site Web?

Comme nous le savons tous, les attaques XSS sont dangereuses et très faciles à réaliser . Divers cadres facilitent le codage HTML, comme le fait ASP.NET MVC:

<%= Html.Encode("string"); %>

Mais que se passe-t-il lorsque votre client exige qu'il puisse télécharger son contenu directement à partir d'un document Microsoft Word?

Voici le scénario: les gens peuvent copier et coller du contenu de Microsoft Word dans un éditeur WYSIWYG (dans ce cas, tinyMCE ), puis ces informations sont publiées sur une page Web.

Le site Web est public, mais seuls les membres de cette organisation auront accès aux informations publiées sur une page Web.

Comment gérer ces exigences de manière sécurisée? Actuellement, aucune vérification n'est effectuée sur ce que le client publie (car seuls les utilisateurs `` de confiance '' peuvent publier), mais je ne suis pas particulièrement satisfait de cela et je voudrais le verrouiller davantage en cas de piratage d'un compte.

La seule méthode conceptuelle que je connaisse qui réponde à ces exigences est de mettre en liste blanche les balises HTML et de les laisser passer . Y a-t-il une autre façon? Sinon, quel est un moyen sûr de laisser l'utilisateur stocker l'entrée dans la base de données sous quelque forme que ce soit, mais l'afficher uniquement correctement codé et débarrassé des balises incorrectes?

Question connexe

Empêcher les scripts intersites (XSS)

Le moyen le plus simple (pour vous en tant que développeur) est probablement d'implémenter l'une des nombreuses variantes de Markdown , par exemple Markdown.NET ou, mieux encore (à mon humble avis), un éditeur wmd .

Ensuite, vos utilisateurs pourraient coller du HTML simple, mais rien de dangereux, et ils pourraient prévisualiser leurs données saisies et redresser les scrupules avant même de publier ...

La liste blanche est en effet le meilleur moyen de prévenir les attaques XSS lorsque les utilisateurs peuvent entrer du HTML, soit directement, soit à l'aide d'un éditeur de texte enrichi.

A propos de vos autres questions:

Existe-t-il un éditeur WYSIWYG qui inclut la possibilité de créer une liste blanche à la volée?

Je ne pense pas que cela pourrait fonctionner. Pour cela, vous avez besoin d'un code côté serveur et le RTE s'exécute sur le client.

TinyMCE filtre les balises si vous le souhaitez, mais comme cela a lieu dans le navigateur, vous ne pouvez pas lui faire confiance. Voir Extended_valid_elements . TinyMCE (Moxie) suggère également une liste blanche, voir ici .

Dois-je même m'inquiéter à ce sujet car ce ne sera que pour une «publication privée»

Vous devez toujours filtrer le HTML sauf s'il existe des raisons spécifiques de ne pas le faire (très rare). Quelques raisons: a) la fonctionnalité qui est pour les utilisateurs internes aujourd'hui peut-être pour le public demain b) l'accès non autorisé aura moins d'impact

est le meilleur moyen de les laisser le stocker dans la base de données sous quelque forme que ce soit, mais seulement de l'afficher correctement encodé et débarrassé des mauvaises balises?

C'est ainsi que je le préfère. Je n'aime pas modifier l'entrée utilisateur avant de l'insérer dans la base de données pour diverses raisons.

Je fais la même chose. J'utilise TinyMCE et autorise le collage à partir de documents Word. Seules certaines personnes qui gèrent le site peuvent le faire via une zone d'administration. Ceci est sécurisé par l'adhésion à ASP.Net. Je fais simplement le HTML.Encode quand il est envoyé sur le site public.

Vous pouvez utiliser le code ci-dessous si vous le souhaitez avant qu'il ne soit placé dans la base de données, mais vous ne savez pas quel effet de choc cela vous donnerait. Vous devrez peut-être aller avec votre liste blanche.

 /// <summary>
    /// Strip HTML
    /// </summary>
    /// <param name="str"></param>
    /// <returns></returns>
    public static string StripHTML(string str)
    {
        //Strips the HTML tags from strHTML 
        System.Text.RegularExpressions.Regex objRegExp = new System.Text.RegularExpressions.Regex("<(.|\n)+?>");

        // Replace all tags with a space, otherwise words either side 
        // of a tag might be concatenated 
        string strOutput = objRegExp.Replace(str, " ");

        // Replace all < and > with < and > 
        strOutput = strOutput.Replace("<", "<");
        strOutput = strOutput.Replace(">", ">");

        return strOutput;
    }

Une option pourrait être le contrôle d'édition HTML pour .NET (que j'ai écrit).

Il s'agit d'un éditeur HTML WYSIWYM pour .NET, qui ne prend en charge qu'un sous-ensemble des éléments HTML , à l'exclusion<script> éléments: de cette façon, il agit comme une liste blanche.

S'il s'agit d'un usage interne (c'est-à-dire d'un site intranet), le contrôle peut être intégré dans une page Web .

Je n'ai pas intégré la prise en charge du collage à partir de Word, mais j'ai un composant qui est un pas dans cette direction: un convertisseur Doc en HTML ; J'ai donc les blocs de construction que vous pouvez utiliser dans ASP.NET pour convertir un document en HTML, afficher le HTML dans l'éditeur, etc.

Mon IMHO continue de faire confiance à vos utilisateurs jusqu'à ce que vous deveniez public.

Eh bien, il n'y a aucun moyen fiable de répondre à vos besoins. Par exemple, tout éditeur WYSIWYG ne parvient pas à protéger le formulaire en insérant des images avec des URL (piste d'utilisation indirecte, contenu illégal) ou du texte (texte illégal, texte mal orthographié, texte manqué).

Mon point de vue est que si vous pouvez faire confiance à vos utilisateurs, autorisez simplement tout, avertissez simplement les utilisateurs s'il existe un balisage dangereux (pour les éviter des erreurs).

Si vous ne faites pas confiance, utilisez une sorte de balisage spécial (par exemple Markdown).

Dans mon projet, nous utilisons des types spéciaux pour le contenu potentiellement dangereux et des méthodes spéciales pour le rendu et l'acceptation de ce contenu. Ce code a une note élevée dans notre modèle de thread et l'attention est très élevée (par exemple, chaque modification doit être examinée par deux codeurs indépendants, nous avons une suite de tests complète, etc.).