¿Puede un hacker hacerse con el control de todo un sitio web con apenas unas secuencias de código? Una inyección de SQL podría permitir que alguien saquease tu base de datos y lo robase todo, desde credenciales administrativas hasta datos de las tarjetas de los clientes.
Si tu sitio o aplicación no está perfectamente programado, un hacker podría extraer todo tipo de información que nunca pretendiste que se hiciera pública.
¿Qué es un ataque de inyección de SQL y cómo puedes evitarlo?
¿Qué es el SQL?
El SQL es un lenguaje de codificación utilizado principalmente para acceder a información de bases de datos online. Es muy fácil de utilizar porque es intuitivo e incorpora palabras habituales en inglés como comandos.
Por ejemplo, imagina que un cliente está comprando online y escribe la palabra «zapatos» en el buscador de una tienda. Cuando se inicia la función de búsqueda, se empieza a ejecutar un proceso sencillo en segundo plano.
El sitio web utilizará un sistema de gestión de bases de datos (SGBD) que, a su vez, ejecutará algún tipo de SQL. Cuando el cliente busca «zapatos», se crea una secuencia de código utilizando ese lenguaje. Se trata de una consulta SQL.
Esta consulta incluirá algunas especificaciones, como dónde buscar y a qué información acceder. Debería verse así:
SELECT name, description FROM products WHERE category = “shoes”Cuando esta consulta llega a la base de datos, el sistema SGBD leerá la consulta SQL y sabrá qué buscar en la tabla «productos». A continuación, accederá a los nombres y a las descripciones de los artículos de la categoría «zapatos» y enviará esos datos al cliente. Si encuentra diez artículos, enviará diez nombres y descripciones.
Es un proceso sencillo. Pero aquí empiezan los problemas.
¿Qué es una inyección de SQL?
Para llevar a cabo su ataque, un hacker intentará introducir código adicional en la secuencia SQL. A esto se le conoce como inyección.
No obstante, no siempre da sus frutos. El SGBD lee algunos caracteres como comandos de código (SELECT, por ejemplo) y otros como palabras y caracteres normales («zapatos» en este caso).
Si un sitio se programa correctamente, no se producirá ninguna inyección al buscar un comando de código. En su lugar, el sistema leerá el comando como un conjunto de caracteres que no reconoce y devolverá un mensaje en el que podrá leerse algo como «No se ha encontrado ningún artículo».
Sin embargo, si el sistema no ha sido protegido, leerá los caracteres inyectados como un comando SQL auténtico. Aquí es donde las cosas pueden ir mal.
En lugar de utilizar la palabra clave «zapatos», el hacker podría buscar comandos SQL específicos. Cuando se forma la secuencia y se envía a la base de datos, el SGBD leerá la palabra clave que se ha buscado como un comando y la ejecutará en consecuencia.
El daño
Utilizando una técnica llamada «inyección de SQL a ciegas», un hacker puede averiguar exactamente qué SGBD se está utilizando en segundo plano. Sabiendo esto, puede empezar a utilizar el lenguaje SQL apropiado.
Si busca los términos de codificación correctos, puede exigir al SGBD que devuelva una lista completa de las distintas tablas de datos que contiene. Armado con esta información, puede acceder a cada una de las tablas y extraer la información que quiera. Si encuentra una tabla de «usuario», los daños pueden llegar a ser graves.
UNION es un comando de código que permite a los usuarios añadir una consulta adicional a su consulta principal. Los resultados de esta subconsulta aparecerán debajo de los resultados de la consulta principal.
Un hacker podría escribir algo como esto en la barra de búsqueda:
“shoes” UNION (SELECT username, password FROM users);--"Se generaría una secuencia SQL en segundo plano que podría tener este aspecto:
SELECT name, description FROM products WHERE category = “shoes” UNION (SELECT username, password FROM users);--Ahora, además de devolver los resultados de la palabra clave «zapatos», el hacker también podrá ver todos los nombres de usuario y contraseñas de la tabla «usuarios».
Es probable que las contraseñas tengan hash, pero un hacker no tardará mucho en descifrarlas. Si puede averiguar los nombres de usuario de los administradores, podría utilizar un software de fuerza bruta para acceder rápidamente a la cuenta relevante y obtener acceso administrativo a toda la aplicación.
Tipos de inyecciones SQL
Para ayudarte a fortificar tus defensas, debemos profundizar en los distintos tipos de ataques de inyección SQL y desarrollar una comprensión más profunda de este panorama de ciberamenazas
1. Inyección SQL clásica
La inyección SQL clásica, también conocida como inyección SQL en banda, es la forma más frecuente de este ciberataque. Al deslizar código SQL malicioso en los campos de entrada del usuario, los malos actores obtienen acceso no autorizado para manipular, eliminar o incluso ejecutar comandos administrativos en la base de datos afectada. Es esencial ser consciente de esta amenaza común y tomar medidas para prevenirla.
2. Inyección SQL a ciegas
Los ataques de inyección SQL a ciegas, como su nombre indica, obligan a los atacantes a trabajar a ciegas, sin el lujo de tener acceso directo a la salida de la base de datos. En la mayoría de los casos, los atacantes que realizan un ataque SQL a ciegas se basan en una serie de consultas verdaderas y falsas para recopilar información. Esta forma de operar permite a los atacantes deducir el esquema y el contenido de la base de datos, pieza a pieza.
3. Inyección SQL basada en errores
Las inyecciones SQL basadas en errores aprovechan los mensajes de error de la base de datos para revelar información sensible. Los atacantes que están detrás de estos ataques envían intencionadamente consultas SQL malformadas, haciendo que la base de datos genere mensajes de error que contienen información valiosa. Analizando detenidamente estos mensajes, los ciberdelincuentes pueden conocer el funcionamiento interno del sistema e identificar sus (de los sistemas) posibles puntos débiles.
4. Inyección SQL a ciegas basada en el tiempo
Las inyecciones SQL a ciegas basadas en el tiempo son un tipo más específico de ataque de inyección SQL a ciegas. Los atacantes que realizan ataques SQL a ciegas basados en el tiempo se centran en el tiempo de respuesta de la base de datos para deducir información. Al enviar consultas SQL que provocan retrasos en la respuesta, pueden conocer detalles específicos sobre la base de datos basándose en el tiempo que se tarda en recibir una respuesta.
5. Inyección SQL fuera de banda
Los ataques de inyección SQL fuera de banda utilizan un canal de comunicación independiente para enviar y recibir datos, en lugar del canal directo entre la aplicación y la base de datos. Este método de ataque, menos común pero potente, permite a los atacantes eludir determinadas medidas de seguridad, como cortafuegos y sistemas de detección de intrusos, para llevar a cabo sus objetivos maliciosos.
¿Qué riesgos conlleva una inyección de SQL?
Los ataques de inyección de SQL plantean una variedad de amenazas de seguridad para la organización afectada. Una vez que los ciberdelincuentes se aprovechan de una vulnerabilidad de inyección de SQL, pueden:
- Añadir, eliminar o modificar el contenido de la base de datos.
- Redactar nuevos archivos en la base de datos.
- Leer el código fuente del servidor de la base de datos.
Todo ello podría incluso derivar en una toma de control completa de las bases de datos y del servidor web, algo que, evidentemente, podría ser desastroso.
Cómo evitar una inyección de SQL
Si la inyección de SQL tiene éxito, las consecuencias pueden ser catastróficas. Un hacker puede robar contraseñas e información de pago, filtrar datos de los usuarios online y eliminar información fundamental. Un evento de este calibre podría socavar de forma irreversible la confianza de los consumidores. ¿Cómo puedes evitarlo?
Validación de los datos introducidos
Si incorporas un proceso de validación de entradas en la codificación del backend de tu sitio, puedes contribuir en gran medida a reducir la amenaza. Podrías crear una lista de caracteres aceptados y programar el SGBD para que reconozca si una palabra clave no está en la lista. Si un hacker "busca" un comando de codificación, tu sistema lo cotejará con la lista permitida. Cuando no obtiene ninguna coincidencia, no ejecuta el código.
Sentencias preparadas
Crear sentencias preparadas es probablemente la mejor estrategia. Un sitio vulnerable crea una nueva cadena de SQL cada vez que el hacker realiza una búsqueda, pero este no es el caso con una sentencia preparada. Cuando programes el backend de tu sitio, crea tus plantillas de SQL de antemano con un signo de interrogación en el lugar de la palabra clave. Puedes programar el SGBD para que lea ese signo de interrogación como cualquier dato de la barra de búsqueda, pero la consulta en sí ya está preparada. Esto reduce radicalmente el riesgo de que un comando SQL malicioso entre en la base de datos.
Segregación de datos
Cuanto más segregados estén tus datos, menos podrá apoderarse de ellos un hacker en un solo ataque. En el ejemplo de la tienda online que hemos comentado antes, el problema de la debilidad SQL se agrava mucho más por el hecho de que los datos de los usuarios se guardan en la misma base de datos que las listas básicas de productos. Separar diferentes tipos de información en bases de datos y servidores distintos limita la cantidad de daño que puede causar un ataque SQL.
Uso de las tecnologías más recientes
Asegúrate de utilizar la última versión de las herramientas de desarrollo para garantizar la máxima seguridad. Las tecnologías de desarrollo web más antiguas podrían carecer de protección SQL o podrían tener vulnerabilidades potenciales que los malos actores podrían explotar. Asegúrate de actualizar los componentes de software que puedas utilizar para el desarrollo, porque las actualizaciones están diseñadas para parchear los errores y los posibles problemas de seguridad.