Desarrolladores: Aseguren sus bases de datos

 

Por Máximo Patiño, 14-09-2012

Los desarrolladores/programadores son ese conjunto de personas especialistas en el desarrollo de nuevas soluciones para las tecnologías de la información, muy creativos y dedicados crean de su intelecto mucho de lo que hoy vemos en nuestros computadores, smartphones, video-juegos, etc. En su mayoría, las aplicaciones que desarrollan se conectan a motores de base de datos, y en casos olvidan criterios fundamentales para garantizar la seguridad de la aplicación y su consecuente comunicación con la base de datos:

1- Confianza en la entrada de datos.
Una de las formas mas comunes en que los desarrolladores y programadores ponen en riesgo una base de datos es permitiendo que sus aplicaciones realicen inyección en SQL. Esto puede evitarse utilizando validación de datos y parametrizando los queries de la aplicación hacia la base de datos, en muchos casos la misma base de datos se deja con campos con formatos sin validar, por ejemplo si el dato que se va a guardar en una columna de la base de datos es tipo fecha, esta columna no debe tener un tipo de dato "number" o tipo "char", sino tipo "Date". (Mas sobre tipos de datos).

2- Mostrar los mensajes de errores a los usuarios.
cuando los desarrolladores permiten que se visualicen errores en queries en SQL puede ayudar a los hackers a determinar como funciona la aplicación y la base de datos, exponiendo configuraciones.

3- Jugando con las contraseñas.
En muchos casos he visto como desarrolladores dejan usuarios y contraseñas guardados sin cifrar en bases de datos y archivos de texto por todo un sistema. Este tipo de información sensible puede caer en manos no deseadas.

4- Conectándose con el super usuario.
En la misma linea del punto anterior, en algunos casos se permiten conexiones a la base de datos con usuarios administrador o SA, Esta practica puede provocar otras conexiones administrativas a la base de datos.

5- Los Stored Procedures no son la solución al Inyección en SQL.
Muchos desarrolladores creen que los Stored Procedures son una forma confiable de prevenir ataques por Inyección en SQL, la realidad es que si el código del stored procedure contiene vulnerabilidades, estos pueden ser ejecutados de manera insegura.

6- Código de prueba.
Antes de pasar un programa a producción, se hace necesario revisar si existe código de prueba o basura en el programa, en muchos casos puede ser algún tipo de "backdoor" que conecta hacia la base de datos, quizás no intencionalmente, pero puede presentar serias vulnerabilidades.

7- Cifrado de mala calidad.
Implementar cifrado "hecho a la medida" no es recomendable en ambientes de base de datos, el desarrollador debe considerar usar las mejores practicas para cifrado de sus aplicaciones.

8- El viejo copy-paste.
Un practica muy usada entre los desarrolladores es buscar códigos pre-hechos en internet, lo que se debe evitar es hacer un simple "copy-paste" sin antes revisar el código.

9- Cuidando los backups.
Sabemos el tiempo que conlleva crear bases de datos con data de prueba para desarrollar aplicaciones, es por esto que muchos desarrolladores prefieren restaurar backups de bases de datos en sus estaciones o ambiente de base de datos. Por esto se debe ser muy cauteloso al momento de donde se almacenan los backups y a quien se les permite acceder estos backups.

10- Implementar la arquitectura REST.
La arquitectura REST (Representational State Tranfer puede ser de mucha ayuda, pero muchas herramientas generan interfaces REST directamente hacia la base de datos, esto puede exponer información a un atacante.

Cortesía de DarkReading

Tweet