A la hora de realizar una auditoría de seguridad lógica, uno de los primeros pasos a dar es la recopilación de la mayor cantidad de información “útil” del objetivo a auditar, lo que en el ámbito de la seguridad denominamos como “information gathering”. Dentro de esta fase, podemos incluir el análisis de metadatos obtenidos a partir de ficheros contenedores como pueden ser de tipo pdf, odt, jpg, etc…

Antes de entrar en materia, me gustaría definir lo que son los metadatos de una manera más formal. Curiosamente, si consultamos el diccionario de la real academia española no encontramos este término, pero para ello tenemos la referencia de la wikipedia:

Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad “for educational purposes only” aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. Esta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).

Dejando los detalles técnicos para más adelante, este ataque se basa en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo) para hacer llegar a la base de datos consultas SQL manipuladas, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection“, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.