.NET For Your Information

Un blog más sobre tecnología .NET

Seguridad en Aplicaciones n-layer

with 2 comments


En primer lugar, debemos definir “seguridad” como una serie de tareas o medidas que se deben implementar en todos los procesos de desarrollo de una aplicación n-layer o conformada por multicapas lógicas, con el fin de evitar cualquier tipo de ataque que pueda acarrear consecuencias tales como: pérdida o transformación de datos, mostrar información confidencial a usuarios no autorizados, entre otras.

Desde siempre, los principios de la seguridad en el desarrollo de aplicaciones han sido los siguientes:

1. Autenticación: su fin es determinar que cada usuario es quien dice ser. Formas de implementarla:

  • Uso de login y password, considerando políticas como número de caracteres mínimos que puedan conformar dicho password, o tipo de caracteres por el cual estará formado (caracteres especiales, alfanuméricos, letras mayúsculas), y de esta manera reducir la probabilidad de éxito de los ataques por fuerza bruta.
  • Almacenar password y otros datos confidenciales de manera encriptada en la base de datos. Esto se puede lograr mediante cualquiera de los algoritmos de encriptamiento que trae el .NET Framework desde su versión 2.0. MD5, SHA1, son ejemplo de ellos. Luego de recibir el parámetro mediante la Capa de Presentación, se debe encriptar para su futura inserción o comparación con lo almacenado en la BD. El fin de esta medida es evitar la fuga de información confidencial relativa a la aplicación en los casos que se intente acceder a ella directamente desde la BD.
  • Límite máximo de intentos por usuario. Generalmente se implementa en aplicaciones que requieran un alto nivel de seguridad, y consiste en bloquear (para lo cual deberá tener un atributo relativo a estatus en la tabla Usuario de BD donde se almacenará esta información) a todo usuario que haya excedido el número máximo de intentos fallidos de autenticación, es decir, dupla de login y password incorrecta. Esta forma de protección también se debe a evitar el éxito de ataques por fuerza bruta.

2. Autorización: Se refiere al uso de roles y perfiles, tanto a nivel de la aplicación, como de BD. Su fin es determinar que cada usuario vea y haga justamente lo que le corresponde ver y hacer, sin tener que estar necesariamente limitando su campo de acción dentro de lo que corresponde a sus funciones en la aplicación.

Genralmente, el rol de un usuario es establecido a priori y almacenado en la BD, para que, a partir de éste, se pueda saber, desde la aplicación, que componentes pueden ser mostrados en su sesión. Dependiendo de la finalidad o funcionalidad del proyecto que estés desarrollando podrás escoger entre “no mostrar” o “bloquear” los componentes. Si deseas que un rol en específico no sepa de la existencia de ciertas funcionalidades, lo ideal es que no muestres dichos componentes, y en caso contrario, lo mejor es bloquearlo, para que el usuario sepa que dicha funcionalidad existe, y que para acceder a ella sólo deberá modificar su perfil, siguiendo determinados procesos definidos por su organización.

3. Auditoría: Consiste en dejar una traza o huellas de quién hizo qué, cuándo y, si es posible, para qué. Esta información debe ser confidencial y sólo debe estar accesible para los administradores del sistema con mayor privilegio. Lo ideal es que no pueda ser modificada bajo ningún concepto, y es lo que finalmente otorgará credibilidad o confianza al uso de la aplicación. Como norma, se tiene que esta información va almacenada de manera encriptada en la BD, aunque también es posible implementar otras formas de almacenado en distintos lugares físicos y con otras tecnologías como logs de transacciones en archivos planos.

Una vez definidos estos tres aspectos, también debemos tener en cuenta cuáles son las mejores prácticas a seguir mientras codificamos.

Prevenir el SQL Injection. Desde la Capa de Presentación, encargada de validar y recolectar datos, debemos crear funciones que nos permitan identificar si ciertos parámetros podrían estar siendo usados con fines de SQL Injection. En resumen, estas rutinas deberán validar que no existan caracteres como: (;) (‘ ‘) (” “) entre otros. Cabe destacar, que el .NET Framework también tiene su librería propia para la validación de datos, System.Text.RegularExpressions, la cual también podrá ser de utilidad para lograr prevenir estos ataques. Mientras que el Enterprise Library también provee el Validation Application Block que persigue el mismo fin.

Nunca escribir parámetros de configuración o información sensible en el código de la aplicación, ó hacerlo de manera encriptada. Para el caso de los Connection String, una práctica recomendada es hacer uso del Enterprise Library, específicamente del Data Access Application Block, el cual es capaz de encriptar dicha cadena de conexión y almacenarla en el app.config o web.config, según sea el caso.

Implementar políticas de manejo de excepciones. Esto trae dos consecuencias positivas. La primera es la robustez de la aplicación ante cualquier eventualidad esperada o no. La segunda, evitar mostrar información que no deba conocer el usuario final, o posible atacante de nuestro sistema, que le permita tener una idea más clara de cómo está estructurada nuestra aplicación, mediante los mensajes de error transmitidos por defecto. Lo ideal es llevar un log de excepciones, y mostrar mensajes por defecto para cada una de las posibles excepciones determinadas previamente. Para llevar a cabo esta tarea, de nuevo, es de utilidad el uso de Enterprise Library en sus Logging y Exception Handling Application Blocks.

Con esto termino el que, espero, sea el primero de muchos posts.

De antemano, agradezco cualquier aporte que tengan a bien, con el fin de reforzar este contenido.

Anuncios

Written by Alejandro Afonso Spinola

23 julio 2009 a 10:44 AM

2 comentarios

Subscribe to comments with RSS.

  1. Excelente enlace, ahora con tu propio dominio, estas creciendo. Felicitaciones.

    Omar Rojas

    17 noviembre 2009 at 10:25 AM

    • Gracias Omar. Pronto vienen más posts bastante útiles. Saludos,

      Alejandro Afonso Spinola

      17 noviembre 2009 at 11:18 AM


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: