L'activation du double échappement est-elle dangereuse ?

Question

J'ai une application ASP.NET MVC avec une route qui permet de rechercher des choses via /search/<searchterm>.

Lorsque je fournis "search/abc", cela fonctionne bien, mais lorsque je fournis "/search/a+b+c" (correctement codé en url), IIS7 rejette la requête avec l'erreur HTTP 404.11 ( Le module de filtrage des demandes est configuré pour refuser une demande qui contient une double séquence d'échappement. ). Tout d'abord, pourquoi fait-il cela ? L'erreur ne semble se produire que si le mot fait partie de l'URL, mais pas d'une chaîne de requête (/transmit?q=a+b+c fonctionne bien).

Je pourrais activer les requêtes à double échappement dans la section sécurité de mon web.config mais j'hésite à le faire car je ne comprends pas les implications, ni pourquoi le serveur rejetterait la requête "a+b+c" comme partie de l'URL mais l'accepterait comme partie d'une chaîne de requête.

Quelqu'un peut-il m'expliquer et me conseiller sur la marche à suivre ?

Answer 1

Edit: Mise en évidence des sections pertinentes.

En gros : IIS est excessivement paranoïaque. Vous pouvez désactiver cette vérification sans risque si vous ne faites rien de particulièrement imprudent avec les données décodées de l'uri (comme la génération d'URI de systèmes de fichiers locaux par concaténation de chaînes).

Pour désactiver la vérification, procédez comme suit (à partir de aquí ) : (voir mon commentaire ci-dessous pour savoir ce qu'implique le double échappement).

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true"/>
    </security>
</system.webServer>

Si le symbole plus est un caractère valide dans une entrée de recherche, vous pourrez besoin de pour activer "allowDoubleEscaping" afin de permettre à IIS de traiter une telle entrée à partir du chemin de l'URI.

Enfin, une solution très simple, quoique limitée, consiste simplement à éviter le signe "+" et à utiliser "%20" à la place. Dans tous les cas, l'utilisation du symbole '+' pour encoder un espace est no encodage url valide mais spécifique à un ensemble limité de protocoles et probablement largement pris en charge pour des raisons de rétrocompatibilité. Si ce n'est qu'à des fins de canonisation, il est préférable d'encoder les espaces en tant que "%20" de toute façon ; et cela permet d'éviter le problème d'IIS7 (qui peut toujours se produire pour d'autres séquences, telles que %25ab).

Answer 2

Je voudrais juste ajouter quelques informations pour Réponse d'Eamon Nerbonne liés à la " ce qu'il faut faire La partie " " de votre question (sans expliquer le pourquoi).
Vous pouvez aussi facilement modifier les paramètres d'une application particulière avec

1. ouverture de la console avec des droits d'administrateur (Démarrer - cmd - clic droit, Exécuter en tant qu'administrateur)

2. en tapant ce qui suit (extrait d'ici) : http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx ) :

   %windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true

   (vous pouvez par exemple remplacer YOURSITENAME con Default Web Site pour appliquer cette règle au site web par défaut)

3. Entrez, prêts.

Un exemple :

1. Tout d'abord, j'ai eu le même problème :
2. En tapant le texte mentionné ci-dessus :
3. Maintenant, il fonctionne comme prévu :

Answer 3

Avez-vous pensé à avoir l'URL de recherche comme '/search/a/b/c' ?

Vous devez configurer une route comme

search/{*path}

Et ensuite extraire les valeurs de recherche de votre chaîne de chemin dans l'action.

HTHs
Charles

Answer 4

J'ai rencontré ce problème sous IIS 7.5 en faisant un Server.TransferRequest() dans une application.

L'encodage du nom de fichier a causé le problème de double-écriture, mais si je ne l'avais pas encodé, j'aurais rencontré le problème de l'encodage du nom de fichier. "potentiellement dangereux Request.Path" erreur.

L'ajout d'un protocole quelconque, même vide, à l'URL que je passe à Server.TranferRequest() a réglé le problème.

Ne fonctionne pas :

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

Travaux :

context.Server.TransferRequest("://folder/bar%20bar.jpg");