Questions sur l'injection de Javascript

Question

J'ai lu sur le site d'apprentissage de mvc d'asp.net sur l'injection de Javascript et l'homme c'est une révélation.

Je n'ai jamais réalisé/pensé à quelqu'un utilisant JavaScript pour faire des attaques d'injection de cul bizarres. Cependant, il m'a laissé quelques questions sans réponse.

Première

Quand utilisez-vous Html.Encode? Comme l'utilisez-vous uniquement lorsque vous souhaitez afficher des informations que cet utilisateur ou un autre utilisateur a soumises?

Ou est-ce que je l'utilise pour tout. Comme dire que j'ai une forme qu'un utilisateur soumet, cette information ne sera jamais montrée à aucun des utilisateurs, devrais-je toujours employer html.encode?

Comment le ferais-je comme je ne sais pas comment mettre à l'intérieur say et Html.TextBox() la balise html.encode.

Deuxième

Qu'advient-il dire que j'ai sur mon site un riche éditeur HTML. L'utilisateur est autorisé à l'utiliser et rendre les choses en gras et autres. Maintenant, je veux afficher des informations à l'utilisateur via une étiquette. Je ne peux pas Html.Encode depuis lors, tout le gras et les choses ne seront pas rendues.

Pourtant, je ne peux pas le laisser comme c'est le cas depuis ce qui empêcherait un utilisateur d'ajouter une attaque Javascript?

Alors qu'est-ce que je ferais? Utilisez Regex pour filtrer tous les tags?

Troisième

Il y a aussi une autre balise, vous pouvez utiliser appelé « AntiforgeryToken » quand voulez-vous utiliser celui-ci?

Merci

Modifier

Presque tout le monde dit utiliser une « liste blanche » et « liste noire » comment pourrais-je écrire cette liste et la comparer aux valeurs entrantes (exemples en C# serait bien)?

Answer 1

Bonne question!

1. Pour la première réponse, je considérerais la recherche here à une question posée précédente. Comme l'explique la réponse, l'utilisation de HTML Encode ne vous protégera pas complètement contre toutes les attaques XSS. Pour aider à cela, vous devriez envisager d'utiliser le Microsoft Web Protection Library (AntiXSS en particulier), disponible auprès de Microsoft.

2. Comme cela a déjà été mentionné, l'utilisation d'une liste d'étiquettes autorisées est la meilleure chose à faire, laissant les autres à être retirés. Le jeton AntiforgeryToken empêche la falsification de requête (CSRF) car il donne à l'utilisateur un cookie qui est validé par rapport au champ de formulaire rendu lorsque la page est publiée.Il n'y a aucune raison que je sois conscient de cela signifie que vous ne pouvez pas utiliser cela dans toutes vos formes.

Answer 2

Utilisez le codage HTML pour toutes les données affichées qui ont été soumises par un utilisateur. Vous n'avez pas besoin de l'utiliser lors de la soumission dans la base de données sinon vous obtiendriez des données impaires comme: Simon '&' Sons. Vraiment je ne vois pas le mal à l'utiliser sur tout contenu écrit sur la page de façon dynamique.

Utilisez une liste de balises autorisées et supprimez tout le reste pour votre éditeur HTML. Comme les gens l'ont dit, utilisez une liste blanche.

Le troisième est destiné à empêcher une attaque Cross-site request forgery. Vous l'utilisez pour empêcher les personnes de faire un POST en utilisant un cookie 'volé' de l'utilisateur. Vous pouvez donc avoir besoin d'un cookie authentifié avant d'accepter un post, mais un utilisateur malveillant pourrait prendre ce cookie lorsqu'un utilisateur visite son site, puis soumettre un formulaire à votre site en prétendant en être un.

Voir ici pour plus: http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

Comment l'utiliser: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

valident toujours l'entrée reçue contre une liste blanche. Si vous utilisez une liste noire, vous risquez de rencontrer des problèmes d'encodage. Toujours utiliser une liste blanche lors de la validation des entrées. Ne comptez pas sur la validation côté client pour valider l'entrée de l'utilisateur. La validation côté client est idéale pour aider l'utilisateur à entrer des données correctes. Mais un utilisateur malveillant ne l'utilisera pas et pourrait contourner la validation côté client. La validation côté client ne doit jamais être considérée comme un correctif de sécurité. L'utilisation de javascript pour valider l'entrée ne doit pas être utilisée. Comme vous pouvez le voir, javascript est très facile à modifier et à modifier sur n'importe quelle page html. Aussi javascript peut être désactivé dans le navigateur. Donc, donnez une vérification supplémentaire dans votre code derrière le fichier.

De plus, vous validez l'entrée à chaque fois, pas seulement lorsque les données sont initialement acceptées. Par exemple, si vous définissez un cookie, assurez-vous que le cookie a la même valeur et qu'il est correct pour chaque requête. Un utilisateur malveillant peut modifier et modifier la valeur à tout moment au cours de la session.

Answer 4

Différents niveaux de sécurité peuvent être implémentés en fonction des considérations de conception de votre application.

Je voudrais aller avec les règles de base suivantes:

1. Désinfecter toutes les entrées, la suppression des sections malveillants connus (par exemple, <script> balises dans un riche éditeur HTML). La correspondance de motif basée sur Regex est couramment utilisée pour ce type de nettoyage.

2. Supprimez toutes les entrées qui ne figurent pas dans votre liste blanche des valeurs autorisées.

3. Encodez n'importe quel code HTML avant de l'enregistrer dans la base de données et décodez-le lors de son extraction pour affichage.

Modifier: pourparlers de @Phoenix sur la validation dans ce contexte, je pensais que je serais donc ajouter ceci. Je l'ai déjà dit et je le répète: je ne suis pas contre la validation par script. Je conseille seulement aux gens de ne pas s'en prévaloir expressément. Un modèle de conception commun consiste à valider les critères de base à l'aide d'une validation basée sur un script et à appliquer une validation rigoureuse du côté serveur lorsque ces données sont soumises.