Outils de développement · Éditeur HTML WYSIWYG
Désinfection du code HTML collé : éléments à supprimer avant qu'il n'atteigne votre CMS ou votre courrier électronique
· Comment ça marche
html sécurité nettoyage de texte
Explique ce que fait un désinfectant HTML, depuis les balises et attributs autorisés jusqu'aux scripts supprimés et aux URL neutralisées, et comment l'inspection préalable du balisage facilite l'écriture des règles de nettoyage.
L'extrait collé contenant un onclick — s'ouvre avec le risque caché dans la saisie de texte enrichi
Une ancre collée peut masquer un onclick à côté d'une destination innocente. ToolAcre met en minuscules chaque nom d'attribut et ne conserve que les attributs explicitement répertoriés pour l'élément accepté, donc onclick disparaît même lorsque sa casse est modifiée. Le rapport de suppression identifie ce gestionnaire d'événements au lieu de présenter silencieusement la source inchangée.
Cette limite fonctionne avant l'insertion du collage riche, lorsque la source revient en mode visuel, avant la copie, avant l'extraction du texte brut et à nouveau lors de la création des documents d'aperçu. La répétition réduit les contournements accidentels entre les actions, mais le projet refuse toujours d'appeler le tokenizer écrit à la main un filtre XSS à usage général.
Pourquoi les listes autorisées battent les listes de blocage – explique qu'il est plus sûr de nommer ce qui est autorisé que d'essayer de répertorier toutes les constructions dangereuses.
Une liste verte commence par nommer la structure autorisée : paragraphes, titres, éléments sémantiques en ligne, listes, listes de descriptions, citations, éléments de type code et ancres. Un wrapper ordinaire inconnu perd sa balise tout en conservant le texte. Un conteneur dangereux tel qu'un script, un style, une iframe, un formulaire, SVG ou MathML perd également son contenu.
Une liste de blocage devrait anticiper chaque construction dangereuse ou non prise en charge. La liste blanche rejette ce qu'elle ne comprend pas. Il s’agit d’un choix judicieux pour la sortie limitée d’un éditeur, mais il reste limité par son tokenizer. La récupération d'erreur HTML5 du navigateur peut produire une arborescence différente d'un analyseur plus petit lorsqu'une entrée délibérément mal formée est impliquée.
Balises, attributs et schémas d'URL : couvre les trois couches de filtres d'un désinfectant, avec des décisions typiques pour chacune.
Le filtrage s'effectue sur trois couches. Les éléments décident du vocabulaire structurel. Les attributs par élément n'autorisent que quelques valeurs telles que le href et le titre du lien, la citation, le titre de l'abréviation et le début et le type de liste ordonnée. L'inspection d'URL décode ensuite les entités, supprime les contrôles et les espaces d'une sonde et vérifie le schéma résultant.
Les schémas acceptés sont http, https, mailto, tel et ftp, ainsi que les formulaires relatifs sans schéma explicite. JavaScript, données, fichiers, blob, vbscript et environ des exemples sont refusés dans les tests. Les liens survivants gagnent des valeurs relatives, mais cet ajout ne remplace pas la politique de destination ou la révision des liens.
Styles : supprimer, autoriser ou réécrire – discute de la gestion des styles en ligne et des raisons pour lesquelles de nombreux systèmes l'abandonnent complètement
Les attributs de style sont supprimés en gros. Le module ne tente pas d'analyser les déclarations, de conserver un sous-ensemble sécurisé ou de réécrire les jetons de conception. Cette stratégie supprime ensemble l’apparence copiée et les surfaces de requête basées sur CSS. Les attributs de classe, d'identifiant et de données disparaissent également, produisant un balisage portable mais délibérément moins expressif.
Les systèmes avec une véritable exigence de style nécessitent une politique révisée différente. Ajouter du style à cette liste verte sans désinfectant CSS modifierait considérablement sa surface de sécurité. L'implémentation actuelle évite ce problème plutôt que de prétendre résoudre la sécurité CSS pour les fragments hostiles arbitraires.
Exemple concret : dériver la règle de la liste autorisée documentée de ToolAcre, et non d'un appareil spécifique à Word
Commencez par `<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>`. Le div est déballé, la classe et le style ne peuvent pas survivre, onclick est supprimé et le paragraphe ainsi que l'élément fort restent. Le résultat suit la politique générique sans affirmer quelle application a produit le wrapper.
Ajoutez un href javascript et un bloc de script. L'ancre garde ses mots visibles mais perd le href ; le script et le corps disparaissent. Lisez les raisons signalées. Cet exercice permet de définir une politique de serveur, mais copier aveuglément le sous-ensemble exact de ToolAcre peut omettre des éléments dont votre application a besoin ou autoriser des URL interdites par votre modèle de menace.
Nettoyage côté serveur ou côté client : explique pourquoi le serveur doit effectuer un nettoyage même si le navigateur l'a déjà fait.
Le filtrage des clients améliore la rédaction locale, mais ne peut pas être approuvé par un serveur recevant des requêtes contrôlées par l'utilisateur. Les attaquants peuvent contourner la page, appeler directement un point de terminaison ou exploiter une différence d'analyseur. Le serveur doit analyser et nettoyer à nouveau avec une implémentation maintenue compatible HTML5 et configurée pour son contexte de rendu.
Le codage de sortie reste également séparé. Le HTML destiné à être du texte doit être échappé par le modèle plutôt que inséré comme balisage. Un fragment intentionnellement rendu au format HTML doit être nettoyé avant d'être stocké ou sorti selon l'architecture. Un aperçu en bac à sable prouve uniquement que cet aperçu n'accorde aucun script, formulaire ou accès de même origine.
Ce que couvre cet outil : filtrage étroit des sorties de l'éditeur, pas nettoyage général des entrées hostiles
ToolAcre filtre sa propre surface de sortie, contrairement à l'affirmation du classeur selon laquelle il s'agit simplement d'un outil d'inspection. La correction précise est plus étroite : il ne s'agit pas d'un désinfectant XSS à usage général pour les entrées hostiles arbitraires. La source le dit explicitement et documente une éventuelle différence entre les analyseurs.
L'iframe est une défense en profondeur pour le rendu dans ToolAcre. Son attribut sandbox vide n'accorde aucune exécution de script, aucune soumission de formulaire ou accès de même origine, et la politique de référent est sans référent. Une fois le HTML copié ailleurs, ce cadre ne le protège plus. La sécurité des publications appartient au système récepteur.
À retenir : inspectez localement, désinfectez sur le serveur – résume le flux de travail et comment l'éditeur vous aide à voir à quoi un désinfectant sera confronté
Inspectez localement, nettoyez sur le serveur et effectuez le rendu en fonction du contexte. Ce sont trois étapes distinctes. ToolAcre permet de révéler les bagages collés et propose un sous-ensemble de brouillons conservateur, tandis que les avis de suppression rendent visibles les effets des politiques avant qu'un fragment n'atteigne un flux de travail CMS ou de messagerie.
Ne commercialisez pas un aperçu réussi comme preuve contre XSS. Utilisez les charges utiles de test uniquement dans le contenu jetable, conservez la source brute séparément lorsque l'enquête est importante et vérifiez la désinfection de la destination de manière indépendante. Les revendications de sécurité doivent s'arrêter exactement là où s'arrêtent le code et les limites de rendu.