¿En qué piensan los desarrolladores?

El otro día, mirando los archivos que tengo en el ordenador de casa encontré algunos proyectos antiguos en Visual Basic que diseñé hace algunos años. En aquella época trabajaba en una empresa muy pequeña (dos desarrolladores, un administrador de sistemas y “el jefe”), para nosotros todo lo que hacíamos era la mejor opción y los clientes quedaban bastantes satisfechos con nuestro trabajo. Los desarrollos los hacíamos con Visual Basic 6.0 contra bases de datos Microsoft Access y en el mejor de los casos SQL Server 2000; todo Microsoft, por supuesto.

Con los conocimientos de seguridad que he ido adquiriendo a lo largo de mi vida laboral me doy cuenta de que los proyectos que diseñábamos de manera tan “perfecta” tenían… ¡más vulnerabilidades que código escrito!, y que si un usuario malintencionado se hubiera entretenido en explotarlas hubiera destrozado el sistema en cuestión de segundos. Pensando en todo esto me pregunto: ¿Por qué diseñabámos así? ¿No teníamos los conocimientos necesarios? La respuesta es que en ningún momento del desarrollo nos planteábamos la posibilidad de que existieran usuarios malintencionados, o en otras palabras, asumíamos que “los usuarios de nuestra aplicación son demasiado torpes como para hacer esas cosas”. Obviamente, no puedes confiar en que los usuarios de tus aplicaciones vayan a ser “buenos” y no salirse del camino que les dibujas, porque si encuentras uno curioso, puedes llevarte más de una sorpresa desagradable.

Pongamos un ejemplo más técnico. En cierta ocasión, decidimos implementar un proyecto Windows en .Net, y en el app.config establecimos la cadena de conexión a la BBDD junto con el usuario y la clave con permisos de lectura y escritura. Se decidió publicarlo para que nos fuese más cómoda la implantación y las actualizaciones (funcionalidad de .Net que va de “serie” con el Visual Studio 2005). Probamos el funcionamiento de la aplicación una vez publicada y navegamos un poco por los ficheros que nos descargaba el instalador y… ¡sorpresa! El app.config lo había metido en la máquina del cliente (quizá con alguna extensión extra) y si se abría con el Notepad podía verse la cadena de conexión a la BBDD.

Con esta estrategia de implantación y de desarrollo teníamos un sistema poco seguro. ¿Qué opciones se plantean en casos como este?

(a) Presuponer que los usuarios van a conocer la cadena de conexión, el usuario y clave de acceso a la BBDD, por lo que se pueden establecer los permisos pensando en ello.

(b) Si los usuarios no deben conocer nunca datos sobre la BBDD, es necesario realizar un entorno cliente-servidor de manera que nuestra pequeña aplicación utilizada por los usuarios se conecte a una aplicación remota que haga las tareas de BBDD que se le soliciten. De esta manera nuestra aplicación cliente tiene datos de conectividad a nuestra aplicación servidor, pero nunca de la BBDD.

Para evitar todo esto hubiese sido necesario añadir una fase de seguridad adicional en nuestra metodología de desarrollo, en la que entre otras cosas adoptasemos el rol de un posible atacante, probando exhaustivamente todas las posibles casuísticas que hacían vulnerable la aplicación y estudiando la forma de ponerles remedio.

Como desarrollador, debo admitir que todo esto no me lo planteaba en aquella época, ya que diseñaba pequeños proyectos y nunca pensé que existirían usuarios tan “malvados” e “inteligentes” como para explotar posibles agujeros de seguridad. Pero si esos mismos proyectos los desarrollara hoy, por pequeños que fueran, nunca confiaría en que los usuarios lo vayan a utilizar de la manera esperada, sino que me pondría a la defensiva y trataría de pensar: si yo quisiera explotar esta aplicación… ¿qué haría?