Seguridad MVC (Segunda parte).

En el artículo anterior, incursionamos en el tema del código seguro, hablamos brevemente de los posibles descuidos o brechas que un hacker puede aprovechar para vulnerar nuestra seguridad. Hablamos de las capas que debe atravesar un atacante, como el firewall, el servidor, etc. y al final nos hemos enfocamos en lo que a nosotros atañe, que es la seguridad en el código.

Estos artículos servirán como marco teórico para futuras publicaciones cuando hablemos de lo que MVC nos ofrece con respecto a la seguridad en aplicaciones para Internet…

 

Acaso nadie hace nada?

Tal vez en este momento nos sintamos solos, tal vez creamos que nadie hace nada para ayudarnos…después de todo no todos podemos invertir tiempo y esfuerzo en convertirnos en expertos en seguridad.

Bien, en internet existe un grupo denominado OWASP, se trata de una comunidad libre e independiente, que se dedica a tratar temas sobre seguridad en aplicaciones en la red. Ahí podrán encontrar mucho material que se ofrece con licencia de código abierto.

Dentro de este portal encontraran documentos relacionados al tema, entre estos hay uno que nos servirá como tema central en este articulo, me refiero al Top Ten 2013 de ataques.

 

El top ten.

A continuación les comentare brevemente cada uno de estos mecanismos o técnicas de ataque:

1. Injection flaws: Encontraremos en primer lugar uno de los más sencillos mecanismos de ataque; consiste en aprovechar un mal manejo de la validación, de tal forma que nuestra aplicación responde a comandos que el atacante ha escrito en los campos donde debería escribir información. Prevención: evitar concatenar comandos con los datos a nivel de código, los cuales se deben almacenar en una base de datos.
2. Broken Authentication and Session Management: Mala o incorrecta implementación de los mecanismos de registro, autenticación y acceso a nuestra aplicación. Prevención: asegurarnos de estar implementada de manera apropiada la administración de sesiones y el manejo de la autenticación.
3. Cross Site Scripting (XSS): Nuevamente la validación de la información que nos envían es protagonista de otro famoso ataque; en esta ocasión se trata de código de Javascript que puede re direccionar a un usuario, cambiar el contenido de nuestra página e incluso robar la sesión del usuario. Prevención: Conocer los mecanismos que incluye MVC para prevenir este ataque.
4. Insecure direct object reference: Sucede cuando el programador expone algún dato delicado de algún objeto interno, como el nombre del un archivo, el nombre de una carpeta o el ID de un registro en la base de datos. Prevención: Implementar un mecanismos de mapa de acceso por referencias, el cual evita que un posible atacante obtenga información interna que le pueda servir para vulnerar nuestra aplicación.
5. Security Misconfiguration: La seguridad no se da por default. Todos los aspectos relacionados con la seguridad en todos los niveles, tales como el framework, la aplicación, el sistema operativo, el servidor, la base de datos, la plataforma, etc. deben ser implementados de manera explícita. Prevención: Crear un protocolo de publicación, que se asegure que verificar las buenas prácticas al respecto. Mismo que se debe ejecutar en cada publicación. Así mismo es recomendable realizar auditorías de las aplicaciones una vez que están en producción.
6. Exposición de información sensible: Muchas aplicaciones no fueron diseñadas pensando en proteger la información delicada o sensible, como por ejemplo el email, el número de tarjeta de crédito, la dirección, la fecha de nacimiento, etc; esto podría ser usado para robo de identidad, fraude y otras actividades ilícitas. Prevención: Considerar mecanismos tanto internos como externos para controlar el acceso a esta información delicada. Considerar la posibilidad de encriptarla así como deshabilitar el cache de datos cuando no se necesario.
7. Missing Function Level Access Control: La mayoría de las aplicaciones web, validan los privilegios de acceso a nivel de las funciones expuestas en la interface de usuario. Sin embargo el código debe realizar esta validación en todos los niveles, para prevenir que un usuario pueda obtener acceso a una funcionalidad que no le corresponde. Prevención: Debemos negar todos los privilegios por default y asignar únicamente los permisos que les corresponden a cada perfil o usuario ; si existe algún flujo de trabajo, se debe validar el estado de los datos antes de realizar alguna acción o comando empleando estos datos.
8. Cross-Site Request Forgery (CSRF): Este ataque emplea una sesión previamente iniciada para enviar una nueva solicitud, aprovechando que ya cuenta con la información de autenticación lo que engaña al sistema vulnerable al creer que se trata de una petición legitima del usuario. Prevención: Evitar incluir el token de autenticación como parte de la URL y bajo ciertas circunstancias solicitar que verifique que se trata de un usuario, por ejemplo con un CAPTCHA.
9. Usar componentes con conocidas vulnerabilidades: Tal vez esta sea la más común entre todos los programadores, ya que muchas veces las vulnerabilidades no son publicadas o reconocidas por la empresa que creó la biblioteca o componente, lo que ocasiona que estemos expuestos sin estar enterados. Prevención: Hacer una lista con todas las bibliotecas, plugins, controles, componentes y otras referencias que usemos en nuestras aplicaciones y hacer la búsqueda en foros y sitios sobre seguridad, durante las auditorias de seguridad.
10. Re direccionamientos no validados: Las aplicaciones web constantemente re direccionan usuarios a paginas o incluso a otros sitios, enviando información no validada o que al ser recibida no es validada por la aplicación. Prevención: Evitar usar re direccionamientos que expongan parámetros; si no se puede evitar (como sucede en MVC), al menos asegúrense que la información recibida es validada y que se verifica los privilegios de acceso del usuario.

Porque es importante hasta ahora?.

Si son programadores de ASP es probable que no se hayan preocupado jamás antes por estos temas y se hayan limitado a aplicar actualizaciones a sus bibliotecas, ya que MS oculto de tras de una capa de abstracción todo lo relativo al HTML y al HTTP. Así que ellos lidiaban con estos problemas por nosotros.

Como programadores de ASP obviábamos todo lo relativo a estos temas y por consiguiente ignorábamos como podría ser atacada nuestra aplicación y por consiguiente no sabemos qué deberíamos hacer para defendernos. En MVC nosotros interactuamos con el HTTP, por lo tanto nosotros debemos estar al pendiente de estos menesteres; claro que recibimos ayuda tal y como podremos ver en un futuro artículo, pero es nuestra responsabilidad.

 

Que sigue?

En este punto hemos creado una lista de los ataques más comunes, hemos hablado de cómo se presentan y cómo podríamos prevenirlos; es muy importante que entendamos que esto no es algo nuevo, simplemente que la capa de abstracción que lo mantenía oculto, ha desparecido.

En MVC tenemos más control, pero también más responsabilidades, lo que significa que tendremos que aprender sobre un tema nuevo para nosotros.

 

Comentario final.

Espero que esta serie de artículos los ayude poco a poco a ir descubriendo todo lo relacionado a la seguridad en las aplicaciones WEB, desde luego esto no solo afecta a MVC, pero en este caso si queremos aprender a crear aplicaciones en MVC es mejor hacerlo con seguridad desde el principio.

Suerte.