2011-10-12 35 views
66

En mi aplicación ASP.NET MVC, estoy tratando de poner en práctica una URL como la siguiente:secuencia de escape dobles dentro de una URL: El módulo de filtrado de solicitudes está configurado para denegar una solicitud que contiene una doble secuencia de escape

/productos/tags/+ para familias

Cuando trato de ejecutar mi aplicación con configuraciones predeterminadas, estoy consiguiendo este mensaje con el código 404.11 Respuesta:

HTTP Error 404.11 - No encontrado

El módulo de filtrado de solicitudes está configurado para denegar una solicitud de que contiene una secuencia de escape doble.

puedo conseguir un poco con este error mediante la implementación del código de abajo dentro de mi web.config:

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

lo tanto, ahora no estoy recibiendo ningún 404.11.

Lo que me pregunto es qué tipo de agujeros de seguridad estoy abriendo con esta implementación.

BTW, mi aplicación está bajo .Net Framework 4.0 y funciona bajo IIS 7.5.

+0

¿Es posible llegar al recurso deseado utilizando '/ product/tags/for% 20families' en su lugar? Luego tiene una solución alternativa para los identificadores que contienen espacios. ¿O estoy completamente fuera de aquí? –

+0

@atornblad un poco apagado, supongo. Mi pregunta: ** Lo que me pregunto es qué tipo de agujeros de seguridad estoy abriendo con esta implementación. ** – tugberk

+4

IIS está arrojando sobre el carácter "+", que es [el comportamiento predeterminado de Microsoft.] (Http: // blogs .iis.net/thomad/iis7-rejecting-urls-containing) –

Respuesta

46

Los agujeros de seguridad que se pueden abrir tienen que ver con la inyección de código: inyección de HTML, inyección de JavaScript o inyección SQL.

La configuración predeterminada lo protege de ataques semi-eficientes al no permitir que las estrategias de inyección comunes funcionen. Cuanta más seguridad predeterminada elimine, más tendrá que pensar en lo que hace con la entrada proporcionada a través de las URL, consultas de solicitud GET, datos de solicitud POST, encabezados HTTP, etc.

Por ejemplo, si usted es la construcción de consultas SQL dinámicas basadas en el parámetro id de su método de acción, así:

public ActionResult Tags(string id) 
{ 
    var sql = "SELECT * FROM Tags Where tagName = '" + id + "'"; 
    // DO STUFF... 
} 

(... que es NO una buena idea), la protección por defecto, puesto en marcha por el marco .NET , podría detener algunos de los escenarios más peligrosos, como el usuario que solicita esta URL:

/product/tags/1%27;drop%20table%20Tags;%20-- 

La idea es tratar todas las partes de las urls y otras entradas a los métodos de acción como posibles amenazas. La configuración de seguridad predeterminada proporciona parte de esa protección para usted. Cada configuración de seguridad predeterminada que modifique se abre para un poco más de maldad potencial que necesita manejar manualmente.

Por supuesto, supongo que no está creando consultas SQL de esta manera. Pero las cosas más furtivas vienen cuando almacena la entrada del usuario en su base de datos, y luego las muestra. El usuario malvado podría almacenar JavaScript o HTML en su base de datos que sale sin codificar, lo que a su vez amenazaría a otros usuarios de su sistema.

Cuestiones relacionadas