séquence d’échappement double dans une URL: le module de filtrage des requêtes est configuré pour refuser une requête contenant une séquence d’échappement double

Sur mon application ASP.NET MVC, j’essaie d’implémenter une URL comme ci-dessous:

/ product / tags / pour + familles

Lorsque j’essaie d’exécuter mon application avec des configurations par défaut, je reçois ce message avec le code de réponse 404.11:

Erreur HTTP 404.11 – Introuvable

Le module de filtrage des demandes est configuré pour refuser une requête contenant une séquence d’échappement double.

Je peux contourner cette erreur en implémentant le code ci-dessous dans mon fichier web.config:

     

Donc, maintenant je ne reçois pas de 404.11 .

Ce que je me demande, c’est quel genre de failles de sécurité j’ouvre avec cette implémentation.

BTW, mon application est sous .Net Framework 4.0 et fonctionne sous IIS 7.5 .

Les failles de sécurité que vous pourriez rencontrer sont liées à l’injection de code – injection HTML, injection JavaScript ou injection SQL.

Les parameters par défaut vous protègent des attaques de manière semi-efficace en empêchant les stratégies d’injection communes de fonctionner. Plus vous supprimez la sécurité par défaut, plus vous devez réfléchir à ce que vous faites avec les entrées fournies par les URL, les chaînes de requête GET, les données de requête POST, les en-têtes HTTP, etc.

Par exemple, si vous créez des requêtes SQL dynamics basées sur le paramètre id de votre méthode d’action, comme ceci:

 public ActionResult Tags(ssortingng id) { var sql = "SELECT * FROM Tags Where tagName = '" + id + "'"; // DO STUFF... } 

(… ce qui n’est PAS une bonne idée), la protection par défaut, mise en place par le framework .NET, peut arrêter certains des scénarios les plus dangereux, comme l’utilisateur qui demande cette URL:

 /product/tags/1%27;drop%20table%20Tags;%20-- 

L’idée est de traiter chaque partie des URL et autres intrants comme des menaces potentielles. Le paramètre de sécurité par défaut fournit une partie de cette protection pour vous. Chaque paramètre de sécurité par défaut que vous modifiez ouvre la porte à un plus grand nombre de problèmes potentiels que vous devez gérer manuellement.

Bien sûr, je suppose que vous ne construisez pas de requêtes SQL de cette façon. Mais les choses les plus sournoises surviennent lorsque vous stockez des entrées utilisateur dans votre firebase database, puis les affiche plus tard. L’utilisateur malveillant pourrait stocker du code JavaScript ou HTML dans votre firebase database qui ne serait pas codé, ce qui menacerait les autres utilisateurs de votre système.

J’ai donc rencontré ce problème lorsque j’appelais une API à partir d’une application MVC. Au lieu d’ouvrir le trou de sécurité, j’ai modifié mon chemin.

Tout d’abord, je recommande de ne PAS désactiver ce paramètre. Il est plus approprié de modifier la conception de l’application / de la ressource (par exemple, encoder le chemin, transmettre les données dans un en-tête ou dans le corps).

Bien qu’il s’agisse d’un article plus ancien, je pensais partager la façon dont vous pourriez résoudre cette erreur si vous le recevez d’un appel à une API à l’aide de la méthode HttpUtility.UrlPathEncode dans System.Web .

J’utilise RestSharp pour faire des appels, donc mon exemple utilise le RestRequest:

 var tags = new[] { "for", "family" }; var apiRequest = new RestRequest($"product/tags/{HttpUtility.UrlPathEncode(ssortingng.Join("+", tags))}"); 

Cela produit un chemin égal à:

/ product / tags / pour% 2Bfamilies

Sur une autre note, ne créez PAS une requête dynamic basée sur les entrées d’un utilisateur. Vous devriez toujours utiliser un SqlParameter . En outre, il est extrêmement important, du sharepoint vue de la sécurité, de renvoyer les valeurs avec le codage approprié pour éviter les attaques par injection.

~ À la vôtre