2012-07-02 9 views
9

Inspeccioné nuestra aplicación web con la función de auditoría en las herramientas para desarrolladores de Google Chrome.Cómo entender una advertencia de seguridad en google chrome para un recurso estático servido por Asp.net

En primer lugar me dio una advertencia, que indica que estamos sirviendo a nuestro contenido estático ninguno cacheables: "Los siguientes recursos están explícitamente no aplicables a la caché Considere hacer el cacheable si es posible".

Para solucionar este añadí este fragmento a nuestra web-config

<staticContent> 
    <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="7.00:00:00" /> 
</staticContent> 

como se recomienda en esta entrada del blog: http://blogs.msdn.com/b/carlosag/archive/2009/06/09/are-you-caching-your-images-and-scripts-iis-seo-can-tell-you.aspx

Si ahora comienzo a una nueva auditoría en Google Chrome, aparece un nueva advertencia:

Los siguientes recursos públicamente almacenados en caché contienen un encabezado Set-Cookie . Esta vulnerabilidad de seguridad puede hacer que las cookies sean compartidas por usuarios múltiples.

¿Puede explicar la posible amenaza a la seguridad y cuál es una posible solución en Asp.net?

[Actualización]

Después de algunas investigaciones más, supongo que esto podría estar relacionado con esta pregunta:

Why is ASP.NET forms authentication setting cookies on a static image request?

pero no puedo armar el rompecabezas. La situación no es exactamente la misma, mientras que nuestra aplicación podría configurarse para usar autenticación de formularios, recibí la advertencia al usar la autenticación de Windows.

+0

¿Estás seguro de que los dos están conectados por evento? La amenaza de seguridad es bastante clara, la misma cookie podría ser utilizada por múltiples usuarios, esto no es un problema en una computadora de un solo usuario, por supuesto. –

+0

@Ramhound Al menos las herramientas de Chrome piensan que hay una conexión.Si elimino la instrucción de caché del webconfig, recibo otra advertencia en su lugar: los siguientes recursos son explícitamente no almacenados en caché. Considere hacerlos cacheables si es posible: –

+0

Puede agregar el encabezado 'Cache-Control' con un valor 'privado', que indica que el recurso puede ser almacenado en caché solo por un cliente pero no por máquinas intermedias. De esta forma, la misma cookie no debería devolverse a diferentes clientes. –

Respuesta

4

Parece que el problema estaba realmente relacionado con la autenticación de formularios. Después de autenticar al usuario, configuramos un coockie de autenticación de formularios. Este coockie no tiene un conjunto de rutas, por lo que se enviará para cada solicitud, incluso para imágenes estáticas.

Parece que todavía tenía el coockie sistema a partir de una sesión de depuración anterior a pesar de que estaba poniendo a prueba la autenticación de Windows.

Creo que la mejor solución sería la de establecer una ruta para el coockie para evitar que sea enviado por los recursos estáticos. Lamentablemente, no puedo definir una ruta para todas nuestras solicitudes de servicio, porque estamos utilizando WCF Ria Services y los servicios tienen una ruta de acceso virtual creada en tiempo de ejecución.

La solución por ahora se establece la coockie sólo en el navegador. La entrada actualizada en la configuración web es:

<staticContent> 
    <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="7.00:00:00" cacheControlCustom="private"/> 
</staticContent> 

La parte importante es el nuevo atributo CacheControlCustom.

supongo que esto podría ser un problema de seguridad, si un navegador es compartida por más de un usuario (por ejemplo en un cibercafé?), Pero esto no es un escenario válido para nuestro proyecto.

Cuestiones relacionadas