c# - posible - Se detectó un valor Request.Path potencialmente peligroso desde el cliente(*)

se detectó un posible valor request form peligroso en el cliente

Question

Estoy recibiendo el error bastante autoexplicativo:

Se detectó un valor de Request.Path potencialmente peligroso desde el cliente (*).

El problema se debe a * en 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 varios otros filtros.

¿Hay alguna manera fácil de permitir estos caracteres especiales en la URL? Intenté modificar el web.config , pero fue 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 aplicación webforms de c# asp.net que utiliza el enrutamiento para producir la bonita URL anterior.

Answer 1

Cuando se trata de Uniform Resource Locator (URL) existen ciertos estándares de sintaxis , en esta situación particular, estamos tratando con Caracteres Reservados .

Como hasta RFC 3986 , los Caracteres Reservados pueden (o no) definirse como delimitadores por la sintaxis genérica, por cada sintaxis específica del esquema, o por la sintaxis específica de implementación del algoritmo de desreferenciación de un URI; Y el asterisco (*) es un personaje reservado.

La mejor práctica es utilizar caracteres sin reserva en las URL o puede intentar codificar utilizando java.net.URLEncoder .

Sigue cavando :

• Codificación de URL Java de parámetros de cadena de consulta
• Referencia de codificación de URL HTML (w3schools)
• Cuándo codificar o descodificar (RFC 3986)
• Cómo extraer parámetros de una URL determinada

Answer 2

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

Answer 3

El carácter * no está permitido en la ruta de la URL, pero no hay 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 lo codifica o no. Debería codificarlo usando un esquema diferente y luego decodificarlo.

Por ejemplo, usando 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");

Answer 4

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

Se lanzó cuando estaba llamando a un método Web de página .aspx utilizando una llamada al método ajax, pasando un objeto JSON Array. 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 del objeto JSON Actual_Qty contenía "4" (carácter de espacio adicional). Después de eliminar el espacio adicional, la conversión fue posible, el método de la página web fue alcanzado con éxito por la llamada ajax.

Answer 5

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

Answer 6

Para mí, estoy trabajando en .net 4.5.2 con web api 2.0, tengo el mismo error, lo configuré simplemente agregando requestPathInvalidCharacters = "" en requestPathInvalidCharacters tienes que establecer caracteres no permitidos, de lo contrario debes eliminar caracteres que causa 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 reposo, encontré que en la búsqueda, clasificación y paginación, tenemos que manejar el parámetro de consulta como este

/companies?search=Digital%26Mckinsey

y esto resuelve el problema cuando codificamos y volvemos a colocarlo en la URL en% 26 de cualquier forma, en el servidor recibimos el parámetro correcto Digital & Mckinsey

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

Answer 7

Si está utilizando .NET 4.0, debe poder permitir estas URL a través de la 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.