Se detectó un valor Request.Path potencialmente peligroso del cliente (*)

218

Estoy recibiendo el error bastante autoexplicativo:

Se detectó un valor Request.Path potencialmente peligroso del cliente (*).

El problema se debe a *la URL de solicitud:

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

Esta url se usa para completar una página de búsqueda donde 'test *' es el término de búsqueda y el resto de la url se relaciona con otros filtros.

¿Hay alguna manera fácil de permitir estos caracteres especiales en la URL? He intentado modificar el web.config, en vano.

¿Debo codificar / decodificar manualmente los caracteres especiales? O hay una mejor práctica para hacer esto, me gustaría evitar el uso de cadenas de consulta. - Pero puede ser una opción.

La aplicación en sí es una c# asp.netaplicación de formularios web que utiliza el enrutamiento para producir la buena URL anterior.

samdd
fuente
1
¿Tu página tiene ValidateRequest=falseen la parte superior?
Neil Knight
No sé por qué razón el sitio web estaba intentando internamente una redirección que estaba creando una URL como ' localhost /: // localhost / myWebsiteName ' que me estaba dando el mismo error. No sé por qué la tubería de ASP.net lo considera una URL de solicitud peligrosa.
RBT

Respuestas:

97

El *carácter no está permitido en la ruta de la URL, pero no hay ningún problema al usarlo en la cadena de consulta:

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

No es un problema de codificación, el *carácter no tiene un significado especial en una URL, por lo que no importa si la URL la codifica o no. Tendría que codificarlo usando un esquema diferente y luego decodificarlo.

Por ejemplo, utilizando un carácter arbitrario como carácter de escape:

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

Y decodificación:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");
Guffa
fuente
15
El juego "xxx" "xxy" "xyy" es bastante inteligente. Es posible que desee profundizar en la lógica detrás de eso para no confundir a los lectores.
SimpleVar
2
La solicitud era usarlo en PATHy no en la cadena de consulta.
Hugo Delsing
Me encontré con el mismo escenario donde uno de mis parámetros era una URL. Incluso cuando se codifica correctamente la URL, obtendría este error. Finalmente, base64 codificó el parámetro (y lo decodifiqué en mi API), que fue mucho más fácil que tratar de descubrir qué estaba pasando. Probablemente sea una mejor opción que implementar su propia rutina de reemplazo también.
SpokaneDJ
1
¿No puedes usar aa<=> ay ab<=> *como un esquema de codificación más simple?
Palabras como Jared
Por ahora esto me salvó, gracias, pero en el momento adecuado quiero consultar este consejo: stackoverflow.com/a/603962/1830909 y estaré claro si escucho su opinión.
QMaster
316

Si está utilizando .NET 4.0, debería permitir estas URL a través de web.config

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

Tenga en cuenta que acabo de eliminar el asterisco (*), la cadena predeterminada original es:

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

Vea esta pregunta para más detalles.

Dave Transom
fuente
55
¿Hay alguna forma de hacer esto usando un atributo mvc en una acción para no tener que desactivar esto para toda la aplicación? Similar a esta respuesta aquí: stackoverflow.com/a/1540976/298758
longda
44
@longda: Quizás intente envolverlo con un elemento <location path = "my / path"> para la url que necesita. Usar la reflexión sería razonablemente simple desde una perspectiva global, pero no estoy seguro de configurarlo por controlador / acción. Tal vez comenzar una pregunta?
Dave Transom
Simplemente no funciona en el proyecto ASP.net MVC, recibiendo el proceso de ejecución para determinar el diseño en viewStart recibió este error: Carácter ilegal en la ruta.
QMaster
7

Para mí, estoy trabajando en .net 4.5.2 con la API web 2.0, tengo el mismo error, lo configuré simplemente agregando requestPathInvalidCharacters = "" en requestPathInvalidCharacters, debe establecer caracteres no permitidos, de lo contrario, debe eliminar los caracteres que causar este problema

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

** Tenga en cuenta que no es una buena práctica, puede ser una publicación con este parámetro ya que el atributo de un objeto es mejor o tratar de codificar el carácter especial. - Después de buscar las mejores prácticas para diseñar la API de descanso, descubrí que en la búsqueda, la ordenación y la paginación, tenemos que manejar el parámetro de consulta de esta manera

/companies?search=Digital%26Mckinsey

y esto resuelve el problema cuando codificamos & y lo reubicamos en la url en% 26 de cualquier manera, en el servidor recibimos el parámetro correcto Digital & Mckinsey

este enlace puede ayudar con las mejores prácticas de diseño de la API de web de descanso https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

MNF
fuente
6

Debe codificar el valor de la ruta y luego (si es necesario) decodificar el valor antes de buscar.

Tejs
fuente
Gracias por su respuesta. ¿Te refieres a hacer un reemplazo efectivo en elementos como * y luego reemplazarlos nuevamente cuando lo estás leyendo?
¿Puedes mostrar un ejemplo de código de codificación y decodificación de los valores?
Ciaran Gallagher
1

Para mí, al escribir la url, ¿un usuario usó accidentalmente un / en lugar de un? para iniciar los parámetros de consulta

p.ej:

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

que debería haber sido:

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

trykyn
fuente
Sí, incluso lo mismo para mí url.com/endpoint¶meter=SomeValue&otherparameter=AnotherValue
Bhargav Konda
0

Esta excepción ocurrió en mi solicitud y fue bastante engañosa.

Fue lanzado cuando estaba llamando a un método web de página .aspx usando una llamada a método ajax, pasando un objeto de matriz JSON. La firma del método de la página web contenía una matriz de un objeto .NET fuertemente tipado, OrderDetails. La propiedad Actual_Qty se definió como un int, y la propiedad Actual_Qty del objeto JSON contenía "4" (carácter de espacio adicional). Después de eliminar el espacio extra, la conversión fue posible, el método de página web fue alcanzado con éxito por la llamada ajax.

Berta
fuente
0

Intente configurar el servidor del proyecto web correctamente como Local IIS si es IIS Express. Asegúrese de que la URL del proyecto sea correcta y cree un directorio virtual.

Burk
fuente
0

Cuando se trata de localizadores uniformes de recursos (URL) hay ciertos estándares de sintaxis , en esta situación particular estamos tratando con caracteres reservados .

Hasta RFC 3986 , los caracteres reservados pueden (o no) definirse como delimitadores por la sintaxis genérica, por cada sintaxis específica de esquema o por la sintaxis específica de implementación de un algoritmo de referencia de URI; Y el asterisco (*) es un carácter reservado.

La mejor práctica es utilizar caracteres no reservados en las URL o puede intentar codificarlo.

Sigue cavando :

Roshana Pitigala
fuente
1
Este error también ocurre si el carácter reservado en la URL está codificado en porcentaje, por ejemplo, en %25lugar de %, por lo que IIS puede devolver este error para una URL perfectamente válida.
Florian Winter el