Code, Hack & Rock n’ roll (1/3)

No es secreto para los que trabajamos en el área de TI que la seguridad es un tema poco interesante para nosotros los desarrolladores. Normalmente vemos a los “hackers” como nuestros enemigos, que nos hacen sentir humillados cada vez que consiguen alguna vulnerabilidad en nuestras aplicaciones.

Sin embargo esta relación no debería ser así, si desarrolladores y especialistas de seguridad logran acercarse, trabajando juntos desde el inicio de un proyecto, del mismo bando como un solo equipo y no como enemigos que se enfrentan a muerte.

Por eso he decidido escribir este artículo, que se divide en 3 entregas, con la idea de concientizar a los desarrolladores sobre la importancia de la Seguridad Informática.

Code

Inicia un proyecto y lo primero que queremos hacer nosotros los desarrolladores es servirnos una gran taza de café y empezar a escribir código. Nos llenamos de una ansiedad enorme por querer tener funcionalidades implementadas, por demostrar que podemos superar ese desafío que han colocado dentro de nosotros, o simplemente por querer terminarlo antes del tiempo estimado.

Finalmente nos llenamos de satisfacción cuando terminamos de implementar esa funcionalidad o desarrollar toda esa aplicación entera. Sin embargo, esa falsa satisfacción nos dura poco cuando empezamos a sufrir las consecuencias de haber dejado a un lado aspectos de calidad y/o seguridad, cometiendo en la mayoría de los casos, errores comunes que pudimos haber evitado.

10 errores comunes que cometemos los desarrolladores

Desarrollar nuestros propios métodos de seguridad

No, usar nuestros propios métodos de seguridad no será más seguro que usar los ya existentes. Las librerías de seguridad como las de OWASP, Apache o Bouncy Castle son constantemente probadas por toda una comunidad de expertos en seguridad, así que son menos propensas a incluir agujeros de seguridad.

Acceder a una base de datos directamente, con la información suministrada por el usuario

Este es uno de los errores más comunes, sobre todo en aplicaciones web. Aquí aplica el dicho: “Piensa mal y acertarás”. Así que nunca confiemos ciegamente en la información que suministra un usuario, ya que algún usuario malicioso podrá inyectar secuencia de comandos o acceder a datos de nuestra base de datos.

Enfocarnos en los componentes y no en la aplicación entera

Cuando se trata de grandes proyectos, es muy probable que los desarrolladores trabajemos en difertentes partes de la aplicación y nos concentremos en componentes individuales, y tal vez cada uno de nosotros haga su mayor esfuerzo por crear un componente seguro. Sin embargo, muchos problemas de seguridad no ocurren dentro de los componentes sino durante las “transferencias” de datos que fluyen a través de los procesos de negocio. Recuerda, nuestra aplicación será tan fuerte como su punto más débil.

Agregar seguridad al final de la etapa de desarrollo

La seguridad no es algo simple que podamos añadir al final. Es algo que debemos incorporar con la arquitectura de nuestra aplicación. Preocuparnos porque nuestras funcionalidades anden correctamente y luego asegurarlas, es una postura que solo aumenta el riesgo de crear defectos de seguridad a nivel de arquitectura. Es realmente díficil tener que lidiar con cosas como Cross Site Request Fogery y diferentes tipos de Injections después de que la aplicación esté complemente implementada.

Permitir a los usuarios crear contraseñas débiles

Los usuarios tienen malos hábitos de seguridad al momento de crear contraseñas. De hecho, la contraseña más popular es: 123456. Como desarrolladores no podemos permitir que los usuarios creen contraseñas débiles. Y no me refiero a contraseñas complejas, que no necesariamente son las mejores, ya que forzamos a los usuarios a crear contraseñas que nunca recordarán y los incitará a prácticas inseguras, como escribir su contraseña o almacenarla en su computadora. Las mejores contraseñas son largas y fáciles de recordar.

Almacenar contraseñas en texto plano

Nunca debemos almacenar contraseñas en texto plano. Si la base de datos se ve comprometida, no habría que poner en riesgo la data del usuario, especialmente las contraseñas. Y aunque suena muy lógico, es uno de los errores más comunes que cometemos. Más adelante escribiremos un artículo enfocado al almacenamiento adecuado de credenciales.

Almacenar información sensible sin cifrar

Solo porque un motor de base de datos requiera un usuario y contraseña, no quiere decir que alguien no pueda acceder a datos y obtener información. Debemos cifrar información sensible como datos personales, datos de tarjetas de crédito, información financiera o de salud.

Enviar información sensible a través de la URL

Una práctica peligrosa y común que tenemos, es pasar variables o información sensible como parte de la URL. Como desarrolladores debemos evitarlo, ya que podemos abrir las puertas para que atacantes exploten nuestra aplicación o servidor.

Crear autorizaciones y validaciones solo del lado del cliente

Cada vez vemos en incremento la tendencia de desarrollar aplicaciones del lado del cliente. Confiamos en el navegador del cliente para que haga el trabajo que antes era parte del servidor, lo que crea una gran falta de control desde el punto de vista de seguridad porque no sabemos qué tipo de cliente se está utilizando. Incluso, puede no ser un navegador en lo absoluto. No debemos confiar en nada que ocurra del lado del cliente. Si bien las aplicaciones pueden llegar a ser más rápidas y potentes, podemos llegar a crear problemas de seguridad si las funciones críticas (especialmente autorizaciones y validaciones) no las gestionamos correctamente.

Asumir que no nos pasará

Este quizás es el más peligroso de la lista. Lamentablemente muchos de nosotros asumimos que nuestra aplicación no será atacada, o peor aún, que no cometeremos errores. Ambos supuestos nos llevan a prácticas de seguridad débiles. Todo el mundo comete errores, lo importante es poder encontrar esos errores antes de que lo hagan los atacantes. De ser así, estamos en buena forma. Esta mentalidad nos ayudará a evitar brechas de seguridad. Hay herramientas gratis y de código abierto como OWASP ZAP que nos pueden ayudar a escanear nuestras aplicaciones para detectar problemas comunes antes de liberar a producción.

Finalmente, toda esa ansiedad y esa emoción por desarrollar nuestra aplicación, nos da como resultado un producto que en vez de tener features, tiene bugs en esmoquin. Y todo esto por pensar que la seguridad no es algo por lo que tengamos que preocuparnos nosotros. Recordemos que no importa el lenguaje en que programemos, o los años que tengamos haciendolo. En algún momento podemos llegar a cometer algunos de los errores de la lista. Lo importante siempre, será la actitud de cómo los afrontemos.

En la siguiente entrega hablaré sobre la importancia de la seguridad a nivel de la aplicación.