Estos últimos días ha saltado a la palestra el último gran fallo de la Administración Digital en España, el caso Lexnet. En román paladino, como veremos a continuación, tal vez millones de datos de casos, notificaciones y otros tipos de informaciones legales, muchas de ellas sub-iudice, han podido estar en peligro de publicarse o se han publicado, debido a un fallo garrafal en la programación del sistema promovido por el Ministerio de Justicia. Siete millones de euros que son siete millones de errores a efectos prácticos.
Se trata de un error clásico pero que esperas que tenga un programador de PHP novel que no conoce las mínimas prácticas de seguridad. Las inyección de datos en las consultas SQL es más viejo que el comer, y todos los que nos dedicamos a esto hemos descubierto brechas de este tipo, incluso en organizaciones importantes como multinacionales. Pero estamos hablando de que ha sido posible realizar una inyección SQL en un proyecto de siete millones de euros para nada menos que la gestión de datos del sistema legal estatal. ¿Cómo ha sido posible? Hay varias posibles causas, pero la más probable es que simplemente, los programadores no hayan hecho bien su trabajo.
En términos generales, una sentencia SQL es una instrucción del motor de la base de datos que se está usando para obtener o ingresar datos en dicha base de datos. Dicha instrucción es por si misma una cadena de texto. Hasta aquí todo bien. El problema es que sobre todo los programadores poco experimentados suelen cometer un error de juicio con respecto a estas cadenas, y es precisamente tratarlas como cadenas de texto. Aunque tengan esa forma, deberían ser tratadas de forma aislada y encapsulada, ya que concatenarlas o inyectar texto en su interior da lugar a que si no se controla lo que está llegando desde una variable (sea propia o del mundo exterior), entonces estamos exponiendo nuestra base de datos al mundo de manera indiscriminada. Para evitar este tipo de problemas se han inventado varios mecanismos: desde evitar generar consultas como cadenas convirtiéndolas en objetos a los llamados parámetros, que permiten tratar la consulta como si fuera una entidad estática e inmodificable, con aportes de seguridad que permiten que no pueda ocurrir algo así. Porque en efecto, todo apunta a que eso es lo que ha pasado: se ha modificado dinámicamente la sentencia y eso ha hecho que se pudiera manipular la base de datos a voluntad. Vamos, una inyección SQL de toda la vida, pero que esperas que cometa un newbie, no un experto programador para la Administración Pública.
El problema tal vez no sea sólo ese. Es común en este tipo de proyectos que los programadores sean sub-contratados y sub-sub-contratados ad-infinitum con lo que al final no se tiene un mínimo control sobre lo que está haciendo todo el mundo involucrado. Y hay otros problemas anexos como que el servidor ni siquiera estuviera bien asegurado, permitiendo además descargar grandes cantidades de información del proyecto. Un desastre mayúsculo, vamos. En 2007, tras la realización de una web descomunalmente cara (14 millones de euros), la web del congreso también fue comprometida de manera patente, siendo esto un suma y sigue que nos hace preguntarnos si las personas encargadas de este cometido (controlar los proyectos digitales del estado) están realmente haciendo su trabajo.
PD: En Minerva Software Factory, como en cualquier empresa responsable, es imposible que ocurra esto, debido a las reglas de implementación que nos impiden tratar las sentencias SQL como cadenas, entre otros muchos factores de seguridad de una aplicación. Recomendamos mirar con lupa quien desarrolla sus aplicaciones porque a la larga, el problema puede ser muy importante.
Minerva Software Factory 