¿ASP.NET MVC es vulnerable al ataque de relleno de Oracle?

Question

¿Es ASP.NET MVC 2 vulnerable al oracle padding attack? Si es así, ¿qué solución debería implementarse? Las instrucciones en el blog de Scott Gu parecen ser solo para Webforms.

yo probamos este: sin embargo

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="/Home/ErrorPage" /> 

, http://www.example.com/PageThatDoesNotExist todavía devuelve una página de error 404 estándar.

EDIT: Veo que Scott Gu publicó en los comentarios en su publicación de blog que MVC es vulnerable, pero todavía no está claro exactamente cómo implementar la solución.

Answer 1

Yes - vínculo con el comentario de Scott Guthrie.

sábado por la, 18 de de septiembre de, 2010 21:00 por ScottGu

@Vijay,

¿El ASP.NET MVC también se vea afectado?

Sí, todas las versiones de ASP.NET se ven afectadas, incluido ASP.NET MVC.

Gracias,

de Scott

veo que usted ha visto el comentario, pero si se ejecuta el script vbs en su servidor, debe saber si sigue siendo un problema.

Editar: Además, Scott ha discutido las preguntas frecuentes en una nueva publicación here.

Answer 2

En la ruta por defecto que podría/debería agregar esto para empezar

routes.MapRoute("Catch All", "{*path}", new { controller = "Home", action = "ErrorPage" }); 

Editar 2

el problema se encuentra en la parte redirectMode="ResponseRewrite" sin este, funciona.

usando la ruta aunque va a arreglar 1 parte del problema, en que la trayectoria no puede ser encontrado (404)

la siguiente parte, como caminos existentes con de malas identificación u otros datos, podría ser fijado con

<customErrors mode="On" defaultRedirect="/Home/ErrorPage" /> 

¿qué hace exactamente redirectMode="ResponseRewrite" do?

Editar: lo que hace.

redirectMode

• ResponseRedirect: Especifica que la URL para dirigir el navegador a debe ser diferente de la solicitud URL original Web .
• ResponseRewrite: Especifica que la URL para dirigir el navegador debe ser la URL de solicitud web original.

Sólo importa para .NET 3.5 SP1 y .NET 4.0.

Edición 101:

Para redirectMode = "ResponseRewrite" el ASP.NET llama Server.Execute (...) internamente, que no funciona con rutas MVC, por lo que para MVC esto sólo funciona con una archivo HTML estático.

<customErrors mode="On" defaultRedirect="~/Views/Shared/error.htm" redirectMode="ResponseRewrite" /> 

funciona.

Answer 3

¿Tiene una configuración de acción de ruta/controlador para devolver una página de error para la ruta /Home/ErrorPage?

Answer 4

Esta cuestión está incluida en Scott Gu de Frequently Asked Questions about the ASP.NET Security Vulnerability:

afecta esto a ambos ASP.NET Web Forms y ASP.NET MVC?

Sí, el exploit divulgado públicamente se puede usar contra todo tipo de aplicaciones ASP.NET (incluidas tanto Web Forms como MVC).

Answer 5

He publicado mi opinión completa sobre esto (después de una investigación adicional) en my blog.

actualización Nota: se trasladó el enlace a un post específico para ASP.NET MVC

---

Creo firmemente el tema con los 404 se relaciona con WebResources y ScriptResources (que puede desactivar para asp.net MVC btw), ya que probablemente den los 404 cuando no se encuentra el recurso correspondiente (que sería la respuesta normal a un relleno válido que da una ruta/nombre de recurso no válido).

Otros códigos de error & mensajes podrían ser un problema para otras características de asp.net, pero terminando con un 404 solo porque tocó una URL no relacionada con ningún controlador especial no debería estar causando el problema.

También tenga en cuenta lo que he mencionado en esta respuesta: How serious is this new ASP.NET security vulnerability and how can I workaround it?

si la aplicación es asp.net MVC que realmente no necesitamos webresources.axd y/o scriptresources.axd, por lo que aquellos se puede activar apagado. Tampoco usamos viewstate.

El proveedor de membresía asp.net 'almacena en caché' las funciones en las cookies, desactívalas.

La cookie de autenticación está firmada, y de la información en el documento no deberían poder generar una cookie firmada si no llegan a las claves reales (como lo hicieron en el video antes de falsificar la cookie de autenticación))

Como mencionó Aristos, para el ID de sesión en la cookie, eso es aleatorio para la sesión del usuario, por lo que tendría que ser olido por un usuario con el nivel de seguridad objetivo y agrietado mientras esa sesión está activa. Aun así, si confía en la autenticación para asignar/autorizar las operaciones del usuario, entonces el impacto sería mínimo/dependería mucho de la sesión utilizada en esa aplicación.

Answer 6

Se ha publicado un parche para este error en Windows Update.

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx