Ataques por SQLInjection, un clásico

Afortunadamente, cada vez es más difícil encontrar una web vulnerable a un ataque por SQLInjection, en realidad solo es cuestión de aplicar buenas prácticas en el desarrollo. Algo tan sencillo como hacer convenientemente un parseo previo de los datos introducidos en nuestra web, nos puede evitar sobresaltos por ataques como SQLInjection o XSS, por ejemplo.

Aunque por lo general, protegerse ante este tipo de ataques es una práctica habitual, como tan habitual es protegerse ante un fallo inesperado de tu programa, sencillamente con instrucciones Try/Catch, por ejemplo, la verdad es que aún podemos encontrar "descuidos". Estos descuidos son muy fáciles de corregir, pero de no hacerlo a tiempo, si los "señores del sombrero negro" lo descubren, a buen seguro lo van a aprovechar, o sencillamente se van a divertir borrando o manipulando nuestros datos.

De vez en cuando, navegando por la red, cuando accedo a un formulario de Usuario/Contraseña, suelo tener la tentación de comprobar si han sido cuidadosos o no, con la diferencia de que cuando lo encuentro; yo, que soy un caballero :-); aviso de la desprotección.

Por lo general, cuando un formulario de Usuario/Contraseña está un poco descuidado de aspecto, es probable que también esté descuidado en protección.

Algo tan sencillo como introducir una comilla [ ' ] en el campo del Usuario y si al Aceptar tenemos algo así como:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Comilla no cerrada antes de la cadena de caracteres '' AND CLAVE=''.

/xxxx/yyy/login.asp, línea zz

estamos ante uno de estos "descuidos". Ya solo es cuestión de seguir poco a poco para "colarse hasta la cocina". 

En realidad, todo se basa en hacer fallar el procesamiento del formulario y que la información de fallo que nos muestre, nos vaya dando pistas acerca de nombre de tabla, nombres de campos o los propios datos en sí.

No hace falta buscar con demasiado ahínco en la red, para encontrar auténticos manuales de como hacer un SQLInjection. Con esto y unos conocimientos básicos de SQL, en muchos casos es suficiente para colarse en una web, modificar datos o directamente borrarlos, dependiendo de "la mala leche" del que lo encuentre.

No pretendo hacer apología del SQLInjection, ni mucho menos. Cualquiera que tenga el más mínimo interés en el tema, encontrará en la red, información más detallada y precisa de lo que yo pueda mostrar, a modo de ilustración, en este post.  

Como indicaba anteriormente, el proceso consiste en ir provocando sucesivos fallos en cada paso, de forma que cada uno, nos aporte información adicional a usar en los pasos sucesivos.

Veamos un ejemplo:

Para empezar, un primer dato...

Introduciendo como Usuario:  ' HAVING 1=1 -- , el error que se nos muestra, es la punta del ovillo que estábamos buscando:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.IDCLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado y no hay cláusula GROUP BY. 

ya tenemos dos datos, el nombre de la tabla y el primero de sus campos. Ahora a por los siguientes...

Introduciendo como Usuario:  ' GROUP BY CLIENTES.IDCLIENTE HAVING 1=1-- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.NOMBRECLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado ni en la cláusula GROUP BY.

... y así campo por campo hasta conocer la estructura de toda la tabla.

El siguiente paso es hacer fallar el sistema en la conversión de un tipo de dato, para que nos muestre el valor del dato que no se puede convertir.

Introduciendo como Usuario: ' AND CLIENTES.IDCLIENTE IN (SELECT TOP 1 CLIENTES.NOMBRECLIENTE FROM CLIENTES WHERE CLIENTES.NOMBRECLIENTE LIKE '%A%') -- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]Error de sintaxis al convertir el valor varchar 'Mi Nombre de Cliente' para una columna de tipo de datos int.

Este es solamente un ejemplo; que por prudencia no he querido mostrar completo, para ilustrar lo simple que puede ser acceder a unos datos en una web vulnerable a este tipo de ataque. 

Como se puede ver, no hace falta ser un avezado hacker, para realizar este tipo de intrusiones, aunque evidentemente, no todos los casos son tan sencillos como este.

Bases de datos NoSQL, una consecuencia más que una evolución

Desde hace ya unos años, las bases de datos NoSQL se han convertido en una realidad y una herramienta imprescindible para abordar ciertos tipos de problemáticas.

El que sea un modelo utilizado por muchas de las empresas de más éxito en Internet como Google, Twitter, Facebook, LinkedIn, Amazon, etc., le ha dado un aura de moda y algunas empresas se plantean su uso dejándose llevar por la novedad más que por la necesidad.

Tal está siendo el éxito que está teniendo este movimiento, que algunos se apresuran a augurar el fin de las bases de datos relacionales; posiblemente sea el mismo colectivo que pronosticó el inminente fin del Cobol hace 15 años.

El nacimiento

El término NoSQL (  Not only SQL) fue acuñado a finales de los 90 para referirse a las bases de datos distribuidas Open Source no relacionales.

Aunque no es el único ni quizá el más importante, el más conocido y llamativo es que para acceder a los datos, no se utiliza SQL sino que cada una de ellas aporta un API propietario para acceder a los datos, aunque algunas de ellas implementan un lenguaje próximo al SQL.

Con la explosión de Internet, sobre todo la web, en los 90, los requerimientos para gestionar grandes volúmenes de información, se multiplican de forma exponencial, ahora los usuarios de un sistema se miden en millones, el almacenamiento se mide en petabytes, etc. Los sistemas tradicionales no son operativos en este contexto, el concepto “distribuido” cobra un nuevo sentido.

Aunque si somos estrictos, dado que las bases de datos NoSQL serían Open Source, deberíamos excluir las comerciales, pero llevan en el mercado ya varios años soluciones “parecidas”, con diferentes grados de éxito, como podrían ser Lotus-IBM Domino, Tamino de Software AG, etc., pero digo parecidas porque, entre otras cosas, no son soluciones válidas para un modelo en Internet a gran escala.

El teorema CAP

El teorema de Brewer o CAP, dice que dado un sistema distribuido, no es posible asegurar las siguientes premisas de forma simultánea, sino solamente dos de ellas:

-          Consistencia (Consistency): Todos los nodos ven los mismos datos al mismo tiempo.

-          Disponibilidad (Availability): El fallo de uno o más nodos, no impide a los demás seguir funcionando.

-          Tolerancia al particionamiento (Partition Tolerance): El sistema continúa funcionando a pesar de pérdidas en los mensajes.

En el caso de los RDBMS, se le da más importancia a la [C] Consistencia y a la [A] Disponibilidad, que a la [P]Tolerancia al Particionamiento, mientras que en las B.D. NoSQL se da más importancia a la [P]Tolerancia al Particionamiento y en algunas ocasiones a la [A]Disponibilidad.

En este contexto, aparece el concepto BASE (Basically Available, Soft-state, Eventually consistent), como contraposición al modelo tradicional  ACID (Atomicity, Consistency, Isolation y Durability). Ahora las prioridades son otras.

Tipos de bases de datos NoSQL

Una clasificación de estas bases de datos, podría ser:

-          Clave-Valor, como por ejemplo: Dynamo (Amazon), Redis, MemcacheBD, Riak, Tokyo Cabinet o Voldemort (LinkedIn)

-          Orientadas a documentos, como por ejemplo: MongoDB o CouchDB

-          Orientadas a columnas, como por ejemplo: BigTable (Google), HBase (Hadoop), Cassandra (Facebook, Twitter) o Hypertable

-          En grafo, como por ejemplo: InfoGrid o Neo4j

-          Orientadas a objetos, como por ejemplo: db4o, Objectivity/DB o Versant

Muchas de estas bases de datos son variaciones o combinaciones de otras anteriores, dando mayor importancia a una u otra característica para obtener una solución más efectiva del problema que pretenden resolver. Un ejemplo claro de esto es Cassandra, desarrollada inicialmente por Facebook en 2008 y que la describen como un modelo de datos BigTable corriendo sobre una infraestructura de tipo Dynamo.

¿Hacia donde vamos?

Como ya decía al principio, este movimiento no implica el fin del modelo relacional ni mucho menos, de hecho, el uso de los RDBMS, sigue siendo la opción idónea para abordar muchos de los modelos de negocio.

Con la evolución y la expansión del Cloud Computing, sobre todo en su vertiente SaaS, muchos de los sistemas que soporten el negocio de las empresas en la nube, requerirán del uso de estas bases de datos NoSQL.

Los sistemas OLTP seguirán decantándose por los modelos relacionales, mientras que los OLAP, se decantarán en muchos casos por las NoSQL. Seguramente, el modelo que triunfará, será un modelo mixto.

Cuando tenemos que procesar diariamente miles de millones de peticiones, tenemos que tener en cuenta, que no todos los RDBMS son capaces de soportarlo, que el almacenamiento cobra una especial relevancia, que el escalado horizontal no siempre está disponible y que el escalado vertical de los sistemas, tiene un límite, además de un coste elevado.

Por lo general, las implementaciones de los sistemas basados en bases de datos NoSQL, permiten el uso de “Commodity Hardware” (hardware simple y barato) y un escalado horizontal prácticamente sin límites.