L'activation de la double fuite est-elle dangereuse?


136

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

Quand je fournis "search / abc" cela fonctionne bien, mais quand je fournis "/ search / a + b + c" (correctement url encodé) alors IIS7 rejette la demande avec l'erreur HTTP 404.11 ( Le module de filtrage des demandes est configuré pour refuser un requête contenant une double séquence d'échappement ). Premièrement, pourquoi fait-il cela? Il ne semble lancer l'erreur que si elle fait partie de l'URL, mais pas dans le cadre d'une chaîne de requête (/ transmettre? Q = a + b + c fonctionne bien).

Maintenant, je pourrais activer les demandes de double échappement dans la section de 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 demande "a + b + c" comme partie de l'URL mais accepter comme partie d'une chaîne de requête.

Quelqu'un peut-il expliquer et donner des conseils sur ce qu'il faut faire?


7
J'ai également essayé l'option peut-être plus correcte d'appeler Server.Url Path Encode et j'ai fini avec /search/a%2520b%2520cle balisage qui a conduit à une belle erreur "Une valeur Request.Path potentiellement dangereuse a été détectée par le client (%)". Vous ne pouvez pas gagner semble-t-il.
Zhaph - Ben Duguid

Réponses:


158

Éditer: mise en évidence des sections pertinentes.

Fondamentalement: IIS est excessivement paranoïaque. Vous pouvez désactiver cette vérification en toute sécurité si vous ne faites rien de particulièrement imprudent avec les données décodées par uri (comme la génération d'URI du système de fichiers local via la concaténation de chaînes).

Pour désactiver la vérification, procédez comme suit (à partir d' ici ): (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 devrez activer «allowDoubleEscaping» pour permettre à IIS de traiter une telle entrée à partir du chemin de l'URI.

Enfin, une solution de contournement très simple, bien que limitée, consiste simplement à éviter «+» et à utiliser «% 20» à la place. Dans tous les cas, l'utilisation du symbole «+» pour coder un espace n'est pas un codage d'URL valide , mais spécifique à un ensemble limité de protocoles et probablement largement pris en charge pour des raisons de rétrocompatibilité. Ne serait-ce qu'à des fins de canonisation, il est préférable d'encoder les espaces en tant que «% 20» de toute façon; et cela évite bien le problème IIS7 (qui peut encore surgir pour d'autres séquences, telles que% 25ab.)


3
Je désactiverais le chèque. C'est un problème et n'offre pas de sécurité supplémentaire à la plupart des applications.
Eamon Nerbonne

3
Avez-vous un lien / référence qu'il est à peu près sûr de désactiver le double échappement? En outre, qu'est-ce que cette mesure de sécurité empêche exactement de se produire?
Alex

15
Si un uri est à double échappement, alors les composants uri non échappés peuvent eux-mêmes contenir des caractères réservés et ainsi (des parties de) l'URI non échappé peuvent lui-même être un uri valide. En bref, si vous utilisez la chaîne uri sans échappement pour construire de nouveaux uri - en particulier des chemins de système de fichiers - et que vous ne parvenez pas à échapper correctement au nouveau chemin, vous pouvez autoriser l'injection de chemin. L'injection de chemin pourrait permettre à un attaquant de tromper votre programme pour qu'il traite des données qu'il ne devrait pas, ou de le confondre en pensant que deux uri sont différents alors qu'ils sont en fait identiques mais simplement codés différemment.
Eamon Nerbonne


4
@Stijn: Oui: c'est sûr . Tout ce que fait cette vérification est de filtrer les demandes qui pourraient éventuellement être mal interprétées par un code bogué (surtout si vous doublez décodez ou compilez des Uri via string-concat et sans encodage approprié). Vous n'effectuez aucun type de traitement, donc c'est à peu près automatiquement sûr de votre part. Tout bogue devrait se trouver dans le code de base du service de fichiers d'IIS, et je pense que nous pouvons supposer que cela a été très, très minutieusement testé au combat maintenant. Encore une fois, ce contrôle n'a rien d'extraordinaire, il ne fait que renoncer à des éléments qui pourraient être décodés et ressembler à un uri codé .
Eamon Nerbonne

2

Je voudrais juste ajouter quelques informations à la réponse d'Eamon Nerbonne concernant la partie « que faire » de votre question (sans expliquer pourquoi).
Vous pouvez également modifier facilement les paramètres d'une application particulière avec

  1. ouverture de la console avec les droits d'administrateur (Démarrer - cmd - clic droit, Exécuter en tant qu'administrateur)
  2. en tapant ce qui suit (tiré 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 YOURSITENAMEpar Default Web Sitepour appliquer cette règle au site Web par défaut)

  3. Entrez, prêt.

Un exemple:

  1. d'abord j'ai eu le même problème: Erreur HTTP 404.11 - Le module de filtrage des demandes est configuré pour refuser une demande qui contient une double séquence d'échappement.
  2. Taper le texte mentionné ci-dessus: Drupal7-un autre Solution à 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.
  3. Maintenant, cela fonctionne comme prévu: Solution à 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.

1

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

Vous auriez besoin de configurer un itinéraire comme

search/{*path}

Et puis extrayez les valeurs de recherche de votre chaîne de chemin dans l'action.

HTHs
Charles


Le problème est que d'autres caractères encodés en URL (y compris «/» lui-même) pourraient faire partie de la recherche.
Alex

N'avez-vous pas pu encoder tous les '/' qui font réellement partie de la recherche dans '% 2F'?
Charlino

0

J'ai rencontré cela sous IIS 7.5 en effectuant un Server.TransferRequest () dans une application.

L'encodage du nom de fichier a provoqué le problème de double échappement, mais si je ne l'ai pas encodé, je me heurterais à l' erreur "Request.Path potentiellement dangereux" .

Mettre un protocole quelconque, même vide, sur l'URL que je passe à Server.TranferRequest () a résolu le problème.

Ne marche pas:

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

Travaux:

context.Server.TransferRequest("://folder/bar%20bar.jpg");
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.