Preocupaciones de seguridad al trabajar con nuevas tecnologías

Question

¿Encuentra que cuando trabaja con una nueva tecnología que nunca está seguro de qué barreras de seguridad deja su código?

He estado trabajando con formularios web ASP.Net desde hace 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 áreas de seguridad, especialmente cadenas de consulta y viewstate, pero siento que con el tiempo aprendí cuáles eran las vulnerabilidades y me aseguré de no volver 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 dejo abiertos. Esta sola razón casi me desanima con esto. Lo leo como loco por el 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 dejarse expuestos a un ataque?

Edición: A partir Bounty tan curioso para ver si hay alguna opinión más

Answer 1

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

1. Tenga en cuenta lo siguiente: hay tres tipos de vulnerabilidades. Las que son exclusivas del marco que está utilizando (por ejemplo, los problemas del controlador público Ruby on Rails), las que son exclusivas del tipo de aplicación que está creando (p. Ej., Las aplicaciones web tienen que preocuparse por XSS) y las que son exclusivas de su aplicación en particular.
2. Identifique cómo la nueva tecnología que está utilizando mitiga las vulnerabilidades de seguridad del tipo de aplicación. Por ejemplo, ¿cómo mitifica ASP.Net MVC XSS? ¿Cómo mitiga la inyección de SQL? Si no hay respuesta en la documentación, averigüe cómo va a abordar estas clases comunes de vulnerabilidades. Además, tomen pausa porque si el marco no mitiga estos problemas, tal vez los desarrolladores de frameworks no hayan priorizado la seguridad y quizás no hayan escrito un marco muy sólido.
3. Averigua por qué necesitas seguridad y qué estás tratando de proteger. Por ejemplo: ¿su aplicación requiere autorización antes de ver datos confidenciales? De ser así, determine qué funciones proporciona el marco para la autorización.
4. 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 sus problemas que no los buscan.
5. Código de forma defensiva y tenga en cuenta cómo se utiliza la información del usuario. Sea generoso al definir qué es la entrada del usuario. Por ejemplo, los campos querystring o post son obvios, pero en muchos frameworks MVC la URL dicta qué código se ejecuta (por ejemplo, vea la vulnerabilidad Ruby Routes). Tenga muy en cuenta cómo se manejan los datos
6. El estrés prueba su lógica de negocio y descubre cómo se podría abusar de ella.

En resumen: maneje la entrada del usuario cuidadosamente, lea la documentación existente, determine qué seguridad necesita y descubra cómo el marco 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.

Answer 2

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

lo dijiste tú mismo, tu código anterior está lleno de agujeros de seguridad que nunca agregarías a nada que escribas 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 hace bien la primera vez (al menos yo no) es por eso que volver a factorizar es tan genial.

no dejes que esto te impida aprender algo nuevo, haz tu mejor esfuerzo, lee las amenazas de seguridad para tu tecnología y ve. (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.

Answer 3

Supongo que haremos lo que hacemos cada vez que aprendemos algo nuevo como cuando eres un ciclista seguro y cambias a motos que nunca tomas en la autopista el día 1. En mi prototipo de exp ayuda mucho. Pon a prueba tu código intentando realmente romperlo. Leer la nueva tecnología es extremadamente importante. He visto gente saltar a las nuevas tecnologías solo porque suena genial.

Investigue un poco y encuentre cualquier OSS construido con la misma tecnología. Jugar con él puede revelar muchas cosas.

EDIT: ASP.NET MVC OSS ?? Mire el código fuente nerddinner.com y juegue con él. Los colaboradores son de primera clase y supongo que deben haber pensado en la seguridad al crear esto.

Answer 4

Creo que MUCHO de lo que aprendió con ASP.NET es transferible a ASP.NET MVC. Sigue siendo HTML (exploits: XSS) a través de HTTP (exploits: todas las entradas [cookies, parámetros de URL, entrada de formularios, encabezados] pueden falsificarse, secuestro de sesión, CSRF) con un back-end de base de datos (exploits: SQL injection).

Recomendaría Steve Sanderson's libro sobre ASP.NET MVC titulado Pro ASP.NET MVC Framework. Tiene un capítulo completo dedicado a estos temas.

Consulte el Capítulo 13 'Seguridad y vulnerabilidad' del Table of Contents para el libro.

Answer 5

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

Answer 6

Consejo específicamente para ASP.NET MVC:

En su punto de vista, utilice los métodos HtmlHelper tanto como sea posible (por ejemplo Html.BeginForm, Html.TextBox, Html.ActionLink, etc), frente a las etiquetas HTML primas. Los ayudantes codificarán HTML automáticamente los valores que pases, reduciendo las posibilidades de crear una vulnerabilidad XSS.

Para cualquier otra entrada que esté reproduciendo en su vista, siempre use Html.Encode.

Answer 7

Nuevamente, específico de ASP.NET MVC, realmente observa el uso de la vinculación del modelo. Siempre debe especificar explícitamente las propiedades que se vincularán.

No hacerlo puede ocasionar algunos efectos secundarios inesperados (como me enteré ...) y puede permitir que alguien altere las propiedades del modelo.

Answer 8

Mucho de MVC es lo mismo que WebForms, ambos se sientan en Asp.net, como ya ha dicho @GuyIncognito, la mayor parte es igual.

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

Solo que no, puede ser pirateado, el viewstate desperdicia mucho espacio y nunca se puede apagar por completo. En mi opinión, la mejor práctica con WebForms es nunca asumir que la devolución de datos es definitivamente de la página servida y volver a verificar la seguridad de todos modos.

Con las devoluciones de MVC se realizan diferentes acciones, con modelos y carpetas de modelos que encapsulan el contenido en objetos de tipo seguro. Los cheques aún deben ser hechos, ya que falsificar la devolución de datos ahora es mucho más fácil. Entonces:

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

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

MVC incluye soporte token anti falsificación, here's an excellent article on them. ayuda, pero todavía no confiaría en eso.

Todo lo demás (codifica toda la salida generada por el usuario, parametriza todas las entradas Sql, etc.) es la misma.

Answer 9

Simple, nunca confíes en nada que entre en tu aplicación :) Algunas personas ya han hecho algunas buenas publicaciones sobre el hecho de que puedes falsificar cualquier publicación en el framework fácilmente, pero esto no debería ser diferente de las webforms de todos modos desde se puede hacer.

ASP.NET MVC tiene algunas buenas características para validar sus datos, especialmente con v2. Aquí está Scott Gu's post about 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 qué roles tienen permiso para acceder a él. Esto utiliza el marco de autenticación de .NET al igual que los formularios web, por lo que puede implementar su propia seguridad aquí también.

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

Answer 10

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