Une valeur Request.Path potentiellement dangereuse a été détectée par le client (*)


218

Je reçois l'erreur plutôt explicite:

Une valeur Request.Path potentiellement dangereuse a été détectée par le client (*).

Le problème est dû à *l'URL de demande:

https://stackoverflow.com/Search/test*/0/1/10/1

Cette URL est utilisée pour remplir une page de recherche où «test *» est le terme de recherche et le reste de l'URL se rapporte à divers autres filtres.

Existe-t-il un moyen simple d'autoriser ces caractères spéciaux dans l'URL? J'ai essayé de modifier le web.config, en vain.

Dois-je encoder / décoder manuellement les caractères spéciaux? Ou existe-t-il une meilleure pratique pour ce faire, je voudrais éviter d'utiliser des chaînes de requête. - mais cela peut être une option.

L'application elle-même est une c# asp.netapplication de formulaires Web qui utilise le routage pour produire la belle URL ci-dessus.


1
Votre page a-t-elle ValidateRequest=falseen haut?
Neil Knight

Je ne sais pas pour quelle raison le site Web essayait en interne une redirection qui créait une URL comme ' localhost /: // localhost / myWebsiteName ' qui me donnait la même erreur. Je ne sais pas pourquoi le pipeline ASP.net le considère comme une URL de demande dangereuse.
RBT

Réponses:


97

Le *caractère n'est pas autorisé dans le chemin de l'URL, mais il n'y a aucun problème à l'utiliser dans la chaîne de requête:

http://localhost:3286/Search/?q=test*

Ce n'est pas un problème d'encodage, le *caractère n'a pas de signification particulière dans une URL, donc peu importe si votre URL l'encode ou non. Vous devez l'encoder à l'aide d'un schéma différent, puis le décoder.

Par exemple, en utilisant un caractère arbitraire comme caractère d'échappement:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

Et décodage:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

15
Le jeu "xxx" "xxy" "xyy" est assez intelligent. Vous voudrez peut-être élaborer sur la logique derrière cela afin de ne pas confondre les lecteurs.
SimpleVar

2
La demande était de l'utiliser dans le PATHet non dans la chaîne de requête.
Hugo Delsing

J'ai rencontré le même scénario où l'un de mes paramètres était une URL. Même lorsque l'URL est correctement encodée, j'obtiens cette erreur. J'ai finalement juste codé en base64 le paramètre (et décodé dans mon API), ce qui était beaucoup plus facile que d'essayer de comprendre ce qui se passait. Probablement un meilleur choix que la mise en œuvre de votre propre routine de remplacement.
SpokaneDJ

1
Ne pouvez-vous pas utiliser aa<=> aet ab<=> *comme schéma de codage plus simple?
Words Like Jared

Pour l'instant, cela m'a sauvé, merci, mais en temps opportun, je veux vérifier ce conseil: stackoverflow.com/a/603962/1830909 et je serai serein si vous entendez votre pensée.
QMaster

316

Si vous utilisez .NET 4.0, vous devriez pouvoir autoriser ces URL via le web.config

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

Remarque, je viens de supprimer l'astérisque (*), la chaîne par défaut d'origine est:

<httpRuntime 
          requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?" />

Voir cette question pour plus de détails.


5
Y a-t-il un moyen de le faire en utilisant un attribut mvc sur une action, donc je n'ai pas à désactiver cette option pour l'ensemble de l'application? Semblable à cette réponse ici: stackoverflow.com/a/1540976/298758
longda

4
@longda: Essayez peut-être de l'envelopper avec un élément <location path = "my / path"> pour l'URL dont vous avez besoin. Utiliser la réflexion serait raisonnablement simple d'un point de vue global, mais je ne suis pas sûr de la définir par contrôleur / action. Peut-être commencer une question?
Dave Transom

Cela ne fonctionne tout simplement pas sur le projet ASP.net MVC, la réception du processus d'exécution pour déterminer la disposition dans viewStart a cette erreur: caractère illégal dans le chemin.
QMaster

7

Pour moi, je travaille sur .net 4.5.2 avec l'API Web 2.0, j'ai la même erreur, je l'ai définie simplement en ajoutant requestPathInvalidCharacters = "" dans le requestPathInvalidCharacters vous devez définir des caractères non autorisés sinon vous devez supprimer des caractères qui provoquer ce problème.

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

** Notez que ce n'est pas une bonne pratique, peut être une publication avec ce paramètre car l'attribut d'un objet est préférable ou essayez de coder le caractère spécial. - Après avoir recherché les meilleures pratiques pour la conception d'api de repos, j'ai trouvé que dans la recherche, le tri et la pagination, nous devons gérer le paramètre de requête comme ceci

/companies?search=Digital%26Mckinsey

et cela résout le problème lorsque nous encodons & et le remplaçons sur l'URL par% 26 de toute façon, sur le serveur, nous recevons le paramètre correct Digital & Mckinsey

ce lien peut aider sur les meilleures pratiques de conception d'api web de repos https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9


6

Vous devez coder la valeur de l'itinéraire et ensuite (si nécessaire) décoder la valeur avant de rechercher.


Merci pour votre réponse. Voulez-vous dire que vous effectuez un remplacement sur des éléments tels que * et que vous les remettez en place lorsque vous le lisez?

Pouvez-vous montrer un exemple de code d'encodage et de décodage des valeurs?
Ciaran Gallagher

1

Pour moi, lors de la saisie de l'URL, un utilisateur a accidentellement utilisé un / au lieu d'un? pour démarrer les paramètres de requête

par exemple:

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

qui aurait dû être:

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value


Oui, même pour moi url.com/endpoint¶meter=SomeValue&otherparameter=AnotherValue
Bhargav Konda

0

Cette exception s'est produite dans ma demande et était plutôt trompeuse.

Il a été lancé lorsque j'appelais une méthode Web de page .aspx à l'aide d'un appel de méthode ajax, en passant un objet tableau JSON. La signature de la méthode de la page Web contenait un tableau d'un objet .NET fortement typé, OrderDetails. La propriété Actual_Qty a été définie en tant qu'int et la propriété Actual_Qty de l'objet JSON contenait "4" (caractère d'espace supplémentaire). Après avoir supprimé l'espace supplémentaire, la conversion a été rendue possible, la méthode de la page Web a été atteinte avec succès par l'appel ajax.


0

Essayez de définir la propriété du serveur du projet Web comme IIS local s'il s'agit d'IIS Express. Assurez-vous que l'URL du projet est correcte et créez un répertoire virtuel.


0

Lorsqu'il s'agit d'URL (Uniform Resource Locator), il existe certaines normes de syntaxe , dans cette situation particulière, nous avons affaire à des caractères réservés .

Jusqu'à la RFC 3986 , les caractères réservés peuvent (ou non) être définis comme délimiteurs par la syntaxe générique, par chaque syntaxe spécifique au schéma ou par la syntaxe spécifique à l'implémentation de l'algorithme de déréférencement d'un URI; Et l'astérisque (*) est un caractère réservé.

La meilleure pratique consiste à utiliser des caractères non réservés dans les URL ou vous pouvez essayer de les encoder.

Continue à creuser :


1
Cette erreur se produit également si le caractère réservé dans l'URL est codé en pourcentage, par exemple %25au lieu de %, donc IIS peut renvoyer cette erreur pour une URL parfaitement valide.
Florian Winter
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.