Une valeur Request.Form potentiellement dangereuse a été détectée du client

Question

Chaque fois qu'un utilisateur publie quelque chose contenant < ou > sur une page de mon application web, cette exception est lancée.

Je ne veux pas entrer dans la discussion sur la pertinence de lancer une exception ou de faire planter toute une application web parce que quelqu'un a saisi un caractère dans une zone de texte, mais je recherche une manière élégante de gérer cela.

Attraper l'exception et afficher

Une erreur s'est produite, veuillez revenir en arrière et retaper tout votre formulaire à nouveau, mais cette fois ne pas utiliser <

ne me semble pas assez professionnel.

Désactiver la validation des posts (validateRequest="false") évitera certainement cette erreur, mais laissera la page vulnérable à un certain nombre d'attaques.

Idéalement : lorsqu'un post back se produit contenant des caractères HTML restreints, cette valeur postée dans la collection Form sera automatiquement encodée en HTML. Donc, la propriété .Text de ma zone de texte sera quelque chose & lt; html & gt;

Y a-t-il un moyen de faire cela à partir d'un gestionnaire?

Answer 1

Je pense que vous l'abordez de la mauvaise manière en essayant d'encoder toutes les données postées.

Notez qu'un "<" pourrait également provenir d'autres sources externes, comme un champ de base de données, une configuration, un fichier, un flux, etc.

De plus, "<" n'est pas intrinsèquement dangereux. Il n'est dangereux que dans un contexte spécifique : lors de l'écriture de chaînes qui n'ont pas été encodées pour la sortie HTML (à cause de XSS).

Dans d'autres contextes, différentes sous-chaînes peuvent être dangereuses. Par exemple, si vous écrivez une URL fournie par l'utilisateur dans un lien, la sous-chaîne "javascript:" peut être dangereuse. Le caractère de l'apostrophe, en revanche, est dangereux lors de l'interpolation de chaînes dans des requêtes SQL, mais parfaitement sûr s'il fait partie d'un nom soumis par un formulaire ou lu à partir d'un champ de base de données.

En conclusion : vous ne pouvez pas filtrer une entrée aléatoire pour des caractères dangereux, car n'importe quel caractère peut être dangereux dans les bonnes circonstances. Vous devez encoder au point où certains caractères spécifiques peuvent devenir dangereux car ils passent dans une sous-langue différente où ils ont une signification particulière. Lorsque vous écrivez une chaîne en HTML, vous devez encoder les caractères ayant une signification spéciale en HTML, en utilisant Server.HtmlEncode. Si vous transmettez une chaîne à une instruction SQL dynamique, vous devez encoder différents caractères (ou mieux, laissez le framework le faire pour vous en utilisant des requêtes préparées ou autre chose).

Lorsque vous êtes sûr d'encoder en HTML partout où vous transmettez des chaînes en HTML, définissez ValidateRequest="false" dans la directive <%@ Page ... %> de votre(s) fichier(s) .aspx.

Dans .NET 4, il peut être nécessaire de faire un peu plus. Parfois, il est également nécessaire d'ajouter à web.config (référence).

Answer 2

Il existe une solution différente à cette erreur si vous utilisez ASP.NET MVC :

• ASP.NET MVC - les pages validateRequest=false ne fonctionnent pas?
• Pourquoi ValidateInput(False) ne fonctionne-t-il pas?
• ASP.NET MVC RC1, VALIDATEINPUT, UNE REQUÊTE POTENTIELLEMENT DANGEREUSE ET LE PIÈGE

Exemple en C# :

[HttpPost, ValidateInput(false)]
public ActionResult Edit(FormCollection collection)
{
    // ...
}

Exemple en Visual Basic :

 _
Fonction Edit(collection As FormCollection) As ActionResult
    ...
End Function

Answer 3

En ASP.NET MVC (à partir de la version 3), vous pouvez ajouter l'attribut AllowHtml à une propriété de votre modèle.

Cela permet à une requête d'inclure des balises HTML lors de la liaison du modèle en ignorant la validation de la requête pour la propriété.

[AllowHtml]
public string Description { get; set; }

Answer 4

Si vous êtes sur .NET 4.0, assurez-vous d'ajouter ceci dans votre fichier web.config à l'intérieur des balises :

---

Sur .NET 2.0, la validation des requêtes ne s'appliquait qu'aux requêtes aspx. Sur .NET 4.0, cela a été étendu pour inclure toutes les requêtes. Vous pouvez revenir à ne réaliser la validation XSS que lors du traitement des fichiers .aspx en spécifiant :

requestValidationMode="2.0"

Vous pouvez désactiver la validation des requêtes entièrement en spécifiant :

validateRequest="false"

Answer 5

Pour ASP.NET 4.0, vous pouvez autoriser le balisage en tant qu'entrée pour des pages spécifiques au lieu de l'ensemble du site en le mettant tout dans un élément . Cela garantira que toutes vos autres pages sont sécurisées. Vous n'avez PAS besoin de mettre ValidateRequest="false" dans votre page .aspx.

...

...

Il est plus sûr de contrôler cela à l'intérieur de votre web.config, car vous pouvez voir au niveau du site quelles pages autorisent le balisage en tant qu'entrée.

Vous devez toujours valider l'entrée de manière programmatique sur les pages où la validation de la requête est désactivée.