.net - sistema - security asp net mvc

Preocupaciones de seguridad al trabajar con nuevas tecnologías (10)

Creo que mucho de lo que aprendiste con ASP.NET es transferible a ASP.NET MVC. Todavía es HTML (exploits: XSS) sobre HTTP (exploits: todas las entradas [cookies, parámetros de URL, input de formulario, encabezados] pueden ser falsificados, secuestro de sesión, CSRF) con un back-end de base de datos (exploits: inyección SQL).

Recomendaría el libro de Steve Sanderson sobre ASP.NET MVC titulado Pro ASP.NET MVC Framework . Tiene un capítulo entero dedicado a estos temas.

Consulte el Capítulo 13 ''Seguridad y vulnerabilidad'' en la Tabla de contenido del libro.

¿Encuentras que cuando trabajas con una nueva tecnología nunca estás seguro de qué brechas de seguridad dejas en tu código?

He estado trabajando con ASP.Net Web Forms durante aproximadamente 5 años y estoy bastante seguro de que mi código es al menos lo suficientemente seguro como para detener la mayoría de los ataques conocidos. Mirando hacia atrás una gran parte de mi código inicial, sin saberlo, he dejado huecos en muchas de las áreas de seguridad, especialmente las cadenas de consulta y el estado visual, pero siento que con el tiempo he aprendido cuáles eran las vulnerabilidades y me aseguré de que no volviera a cometer los mismos errores.

Sin embargo, recientemente comencé un nuevo proyecto en ASP.Net MVC y realmente no tengo idea de qué agujeros de seguridad estoy dejando abierto. Esta sola razón casi me está quitando el ir con esto. Lo estoy leyendo como loco en este momento, pero estoy seguro de que no he aprendido lo suficiente como para hacerlo lo más seguro posible con Web Forms. ¿Qué hacen ustedes para asegurarse de no estar abiertos al ataque?

Editar: Comenzando Bounty como curioso para ver si hay más opiniones.

De nuevo, específico de ASP.NET MVC, realmente observe el uso de Model Binding. Siempre debe especificar explícitamente las propiedades que se enlazarán.

No hacerlo puede provocar algunos efectos secundarios inesperados (como descubrí ...!) Y puede permitir que alguien altere maliciosamente las propiedades del modelo.

Las tecnologías que utiliza pueden cambiar, pero los problemas subyacentes de seguridad no lo hacen. En todo caso, esperaría menos agujeros de seguridad en el código que usa bibliotecas más nuevas, porque están diseñadas teniendo en cuenta los ataques comunes. Por ejemplo, la inyección SQL simplemente no ocurre con las clases que genera VS2008 a través de DBML.

Simple, nunca confíe en nada de lo que viene en su aplicación :) Algunas personas ya han hecho algunas publicaciones excelentes aquí sobre el hecho de que puede falsificar fácilmente cualquier publicación en el marco, pero esto no debería ser diferente de los formularios web, ya que se puede hacer. .

ASP.NET MVC tiene algunas características interesantes para validar sus datos, especialmente con v2. Aquí está la publicación de Scott Gu sobre v2 que muestra cómo hacer la validación de una manera realmente ordenada. También tenga en cuenta que puede implementar fácilmente sus propios métodos de validación de la misma manera.

La autorización también es la misma, puede decorar su Controlador o Acción con el atributo Autorizar y especificar a qué roles se les permite acceder. Esto utiliza el marco de autenticación de .NET al igual que los formularios web, por lo que también puede implementar su propia seguridad aquí.

En general, me parece mucho más fácil trabajar con estas (la mayoría) de las cosas en MVC Framework, ya que no hay magia detrás de escena. Puede reemplazar casi cualquier cosa en el marco y tiene el control total. Puede que requiera un poco de tiempo para acostumbrarse si has estado trabajando con formularios web, pero estoy seguro de que te encantará una vez que lo hagas.

Sugerencia específica para ASP.NET MVC:

En sus vistas, use los métodos HtmlHelper tanto como sea posible (por ejemplo, Html.BeginForm, Html.TextBox, Html.ActionLink, etc.), en lugar de etiquetas HTML sin procesar. Los ayudantes codificarán automáticamente en HTML los valores que usted ingresa, lo que reducirá las posibilidades de crear una vulnerabilidad XSS.

Para todas las demás entradas que esté reproduciendo en su vista, utilice siempre Html.Encode.

Supongo que hacemos lo que hacemos cada vez que aprendemos algo nuevo, como cuando eres un ciclista confiado y cambias a las motos, nunca lo tomas en la autopista el día 1. En mi exp, la creación de prototipos me ayuda mucho. Pon a prueba tu código intentando romperlo. Leer sobre la nueva tecnología es extremadamente importante. He visto a personas saltar a nuevas tecnologías solo porque suena bien.

Investigue un poco y encuentre cualquier OSS basado en la misma tecnología. Jugar con eso puede revelar muchas cosas.

EDITAR: ASP.NET MVC OSS ?? Mira el código fuente de nerddinner.com y juega con él. ¡Los colaboradores son de primera categoría y asumo que deben haber pensado en la seguridad al crear esto!

Una gran cantidad de MVC es lo mismo que WebForms: ambos se sientan en Asp.net, como ya dijo @GuyIncognito, la mayoría es lo mismo.

La principal diferencia es que WebForms puede validar su devolución: tienen claves únicas en el contenido de la página que confirman que cada devolución proviene de la página que se muestra.

Solo que no lo hace, puede ser hackeado, el estado de vista desperdicia mucho espacio y nunca puede ser completamente apagado. Considero que la mejor práctica con WebForms es nunca asumir que la devolución es definitivamente de la página en la que se sirve y, de todos modos, volver a verificar la seguridad.

Con MVC, las devoluciones de datos se realizan a diferentes acciones, con modelos y encuadernadores de modelos que encapsulan el contenido en objetos de tipo seguro. Las comprobaciones aún deben hacerse, ya que ahora es mucho más fácil falsificar la devolución. Asi que:

Nunca asuma que el modelo es de una fuente particular.
Suponga que el modelo puede estar dañado y no confíe en él.
Trate las acciones del controlador MVC como lo haría con WebMethod o llamadas de servicio: un intento de pirateo puede llamar a cualquiera de ellas, en cualquier orden, con cualquier parámetro.

Todo esto es la mejor práctica en WebForms de todos modos, ahora es más fácil intentar este tipo de pirateo en MVC.

MVC incluye soporte de token anti falsificación, aquí hay un excelente artículo sobre ellos . Ayuda, pero todavía no confiaría en ello.

Todo lo demás (codificar todas las salidas generadas por el usuario, parametrizar todas las entradas de SQL, etc.) es igual.

Una solución simple: suponga que hay agujeros de seguridad en su aplicación y conéctelos fuera de su aplicación. Por ejemplo, restringir el acceso (a través de IIS) a URLS "inseguras" con SSL y / o restricciones de IP.

todo el tiempo.
Cuanto más aprenda, más podrá evitar los agujeros de seguridad en el futuro.

usted mismo lo dijo, su antiguo código está lleno de agujeros de seguridad que nunca agregaría a nada que escriba nuevo. Este es un gran testimonio de su capacidad para aprender y adaptarse a lo que está trabajando.

Creo que estás en el camino correcto con tu forma de pensar, recuerda, nadie lo entiende bien la primera vez (al menos yo no), por eso la re-factorización es tan genial.

No deje que esto le impida aprender algo nuevo, solo hágalo lo mejor posible, lea las amenazas de seguridad para su tecnología y listo. (prueba http://www.securityfocus.com )

las revisiones por pares pueden ayudar con esto y existen herramientas que pueden facilitar la búsqueda de agujeros de seguridad.

Esta es una pregunta muy difícil que probablemente no tenga una gran respuesta. Sin embargo, hay un par de cosas que puede hacer para aumentar la posibilidad de mantenerse seguro al usar nuevas tecnologías.

Tenga en cuenta lo siguiente: hay tres tipos de vulnerabilidades. Los que son exclusivos del marco que está utilizando (por ejemplo, los problemas del controlador público de Ruby on Rails), los que son únicos para el tipo de aplicación que está creando (por ejemplo, las aplicaciones web deben preocuparse por XSS) y los que son exclusivos de su aplicación en particular.
Identifique cómo la nueva tecnología que está utilizando mitiga las vulnerabilidades de seguridad de tipo de aplicación. Por ejemplo, ¿cómo ASP.Net MVC mitiga XSS? ¿Cómo mitiga la inyección SQL? Si no hay respuesta en la documentación, descubra cómo va a abordar estas clases comunes de vulnerabilidades. Además, haga una pausa porque si el marco no mitiga estos problemas, es posible que los desarrolladores de marcos no hayan priorizado la seguridad y no hayan escrito un marco muy sólido.
Averigüe por qué necesita seguridad y qué está tratando de proteger. Por ejemplo: ¿Su aplicación requiere autorización antes de ver datos confidenciales? Si es así, determine qué características proporciona el marco para la autorización.
Busque una sección de seguridad en la documentación. A menudo, los problemas conocidos están documentados, pero las personas se centran tanto en resolver el problema que no lo buscan.
Codifique a la defensiva y tenga en cuenta cómo se utiliza la entrada del usuario. Ser generoso en la definición de lo que es la entrada del usuario. Por ejemplo, la cadena de consulta o los campos de publicación son obvios, pero en muchos marcos MVC, la URL determina qué código se ejecuta (por ejemplo, vea la vulnerabilidad de Ruby Routes). Sé muy consciente de cómo se manejan los datos.
Haga una prueba de estrés con la lógica de su negocio y descubra cómo podría ser objeto de abuso.

En resumen: maneje la información del usuario con cuidado, lea la documentación existente, determine qué seguridad necesita y descubra cómo el marco de trabajo mitiga las clases de vulnerabilidad comunes. Ser consciente de que la seguridad es una prioridad y prestar atención es el 50% de la lucha.