Comment je protège contre les attaques XSS dans des attributs tels que src?

c# html-agility-pack security xss

Question

Donc, je construis un désinfectant C # html en utilisant l’agilité html avec une liste blanche. Cela fonctionne bien, sauf dans des cas comme ceux-ci:

<img src="javascript:alert('BadStuff');" />
<img src="jav&#x09;ascript:alert('BadStuff');"> 

Je ne veux pas autoriser l'attribut src, mais pas les éléments malveillants qu'il contient. Tous les éléments que j'ai consultés viennent de recommander une liste blanche pour les tags et leurs attributs. Comment voulez-vous gérer quelque chose comme ça si? Je sais que cela ne fonctionnera pas dans les nouveaux navigateurs, mais je ne suis pas très familiarisé avec la sécurité et je suis sûr qu'il existe certaines autres choses intelligentes que les attaquants pourraient faire.

Réponse acceptée

Les attaques de script intersite (XSS) exploitent les vulnérabilités de la validation de page Web en injectant du code de script côté client. Les vulnérabilités courantes qui rendent vos applications Web vulnérables aux attaques de script entre sites comprennent l'impossibilité de valider correctement les entrées, le codage de la sortie et la confiance des données extraites d'une base de données partagée. Pour protéger votre application contre les attaques de script entre sites, supposez que toutes les entrées sont malveillantes. Contraindre et valider toutes les entrées. Encodez toutes les sorties pouvant potentiellement inclure des caractères HTML. Cela inclut les données lues à partir de fichiers et de bases de données.

L'un des exemples les plus graves d'attaque de script entre sites survient lorsqu'un attaquant écrit un script pour récupérer le cookie d'authentification qui donne accès à un site de confiance, puis le poste sur une adresse Web connue de l'attaquant. Cela permet à l'attaquant d'usurper l'identité de l'utilisateur légitime et d'obtenir un accès illicite au site Web.

Les vulnérabilités courantes qui rendent votre application Web vulnérable aux attaques de script entre sites incluent:

  • A défaut de contraindre et de valider la saisie.
  • A défaut d'encoder la sortie.
  • Faire confiance aux données extraites d'une base de données partagée.

Des lignes directrices

Les deux mesures préventives les plus importantes pour prévenir les attaques de script entre sites sont les suivantes:

  • Contraindre l'entrée.
  • Encoder la sortie.

Résumé des étapes

Pour empêcher les scripts intersite, procédez comme suit:

Étape 1. Vérifiez que la validation de la demande ASP.NET est activée.

Étape 2. Consultez le code ASP.NET qui génère une sortie HTML.

Étape 3. Déterminez si la sortie HTML inclut des paramètres d'entrée.

Étape 4 . Passez en revue les balises et attributs HTML potentiellement dangereux.

Étape 5 . Évaluer les contre-mesures.

Pour plus de détails, voir la 2e référence.

Les références:

Les scripts entre sites expliqués: Comment prévenir les attaques XSS

Comment: empêcher les scripts entre sites dans ASP.NET


Réponse populaire

Vous pouvez autoriser en toute sécurité l'attribut src, à condition que vous désinfectez et gérez correctement les entrées. Pour ce faire, vous devez d'abord l'assainir via une liste blanche de caractères URL valides, la canoniser et ensuite vérifier qu'elle pointe vers une image valide.

La liste blanche que vous avez mentionnée est la première étape (et une étape importante). Pour mettre en œuvre la liste blanche, supprimez tout caractère non valide pour une URL. Vérifiez également que l'URL est correctement formée, ce qui signifie qu'elle pointe vers une ressource valide à laquelle l'utilisateur doit pouvoir accéder. Par exemple, l'utilisateur ne devrait pas accéder à un fichier local sur le serveur en transmettant file://sensitive.txt ou quelque chose du file://sensitive.txt . Si http ou https sont les seuls protocoles à utiliser, vérifiez que l'URL commence par ceux-là. Si vous êtes extrêmement paranoïaque, vous pouvez totalement rejeter la demande car il est évident qu’elle a été falsifiée. La liste blanche est importante, mais la liste blanche seule ne gardera pas la fonctionnalité sécurisée.

La canonisation est importante car de nombreuses attaques dépendent de la soumission d’URL qui vous emmèneront éventuellement à un certain endroit, mais risquent d’abuser du manque de raisonnement inné de l’ordinateur pour obtenir des résultats qui ne devraient pas. Cela vous aidera également à éliminer les chemins d'accès dupliqués vers la même ressource, ce qui pourrait améliorer les performances (ou du moins vous permettre d'améliorer les performances en ne vérifiant pas à nouveau un fichier connu qui n'a pas changé depuis la dernière fois que vous l'avez vérifié. il est possible d'usurper une date de dernière modification afin qu'un attaquant puisse troquer un fichier malveillant après l'avoir déjà "vérifié et approuvé").

Pour vérifier que vous pointez sur une image valide, ouvrez le fichier et lisez les quelques premiers octets. Ne faites pas simplement confiance à l’extension de fichier, mais vérifiez-la avant d’ouvrir le fichier (pour des raisons de sécurité et de performance). Chaque format d'image a un certain modèle d'octets que vous pouvez vérifier. JPEG est un bon exemple à regarder en premier . Il peut toujours être possible pour un utilisateur malveillant de placer un shellcode ou un autre code d’attaque dans un fichier image contenant les en-têtes appropriés, mais cela est beaucoup plus difficile à faire. Ce sera un goulot d'étranglement des performances, alors planifiez-le correctement si vous le mettez en œuvre.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi