El rápido desarrollo de las nuevas tecnologías ha proporcionado a las empresas no sólo una ventaja competitiva y un aumento de la rentabilidad, sino también un importante quebradero de cabeza en materia de ciberseguridad. Hoy en día, los piratas informáticos pueden realizar ataques tanto manuales como automatizados, que cada día son más sofisticados. Lo curioso es que, aunque algunas de las vulnerabilidades de software más populares son bien conocidas y pueden detectarse fácilmente, se siguen explotando activamente.
Por ejemplo, la inyección SQL se descubrió por primera vez en 1998 y, sin embargo, sigue siendo el principal riesgo para la seguridad de las aplicaciones web, según OWASP. OAdemás, las inyecciones SQL, junto con la fuerza bruta y el uso de credenciales robadas, son responsables de un asombroso 80% de las violaciones de datos en todo el mundo.
Teniendo en cuenta lo extendida que está esta vulnerabilidad web, hemos elaborado una guía completa sobre inyecciones SQL, con las siguientes preguntas:
En este artículo, cubriremos:
¿Qué es la inyección SQL?
Antes de pasar directamente a la definición de la inyección SQL, hablemos primero del propio SQL. SQL (Structured Query Language) es un lenguaje de programación utilizado para acceder y manipular bases de datos.
SQL es utilizado por algunos de los sistemas de gestión de bases de datos más populares como MySQL y Microsoft SQL.
La inyección SQL (SQLi) es un ataque de ciberseguridad dirigido a sitios y aplicaciones web que utilizan bases de datos SQL. Es una técnica de inyección de código que se basa en colocar sentencias SQL maliciosas a través de la entrada web. En otras palabras, un actor de la amenaza o el “malo” prueba una serie de comandos SQL para manipular la base de datos y recibir una respuesta que, con suerte, revelará algunos datos sensibles.
En caso de una inyección SQL exitosa, el hacker puede hacer una de las siguientes cosas:
- Eludir la autenticación
- Robar la identidad de un usuario, incluido un ejecutivo de nivel C
- Recuperar, añadir, modificar o destruir completamente los registros de la base de datos
- Convertirse en administrador
- Realizar otros comportamientos manipuladores
Las inyecciones SQL son tan comunes debido a la prevalencia de sitios web que utilizan bases de datos SQL y a su implementación bastante sencilla.
Económico
Fácil de ejecutar
Gran atractivo del objetivo (datos sensibles y de gran valor)
¿Cómo funciona la inyección SQL?
Las inyecciones SQL son posibles cuando un sitio web o una aplicación web no cuenta con un proceso adecuado de desinfección de entradas. En términos sencillos, el saneamiento de entrada impide que los hackers utilicen caracteres especiales para inyectar código malicioso en el campo de entrada de datos.
Una consulta SQL legítima no es más que una interacción entre el usuario y la base de datos. Por ejemplo, al introducir un nombre de usuario y una contraseña, el usuario solicita acceso al software. Si algunos de los caracteres introducidos no coinciden con las credenciales almacenadas en el servidor, se deniega el acceso.
Sin embargo, si los desarrolladores no fueron cuidadosos y no implementaron una fuerte desinfección de la entrada, el hacker puede utilizar los formularios de entrada para enviar sus propias peticiones a la base de datos introduciendo cadenas de código SQL ejecutable.
Antes de mostrar cómo realizar una inyección SQL, repasemos primero los tipos de inyección SQL para comprender mejor los principios que hacen posible este ataque basado en web.
Tipos de inyección SQL
Dependiendo de la intención del actor de la amenaza y de los controles de seguridad del sistema, se aplican diferentes técnicas de inyección SQL. Repasemos algunos de los tipos de inyecciones SQL más comunes para ser conscientes de los escenarios que dan luz verde a los hackers.
Inyecciones SQL clásicas
La inyección SQL clásica, también conocida como in-band, se basa en un canal de comunicación tanto para realizar el ataque como para recopilar los datos. Se considera la más fácil de implementar y puede filtrar datos a través de ella:
- Mensajes de error. En este caso, el sombrero negro introduce deliberadamente la entrada que dará lugar a un error para obtener información sobre la estructura de la base de datos. Estamos seguros de que ha visto esos mensajes de error confusos que no aportan ningún valor a los usuarios finales pero que contienen detalles técnicos vitales, exactamente lo que los hackers esperan recuperar.
- Operadores UNION. Los piratas informáticos pueden utilizar la palabra clave UNION para ampliar su consulta original combinando dos o más sentencias SELECT. Este tipo de ataque permite realizar consultas cruzadas entre tablas.
Inyecciones SQL ciegas
Este tipo de inyección requiere más paciencia por parte del hacker porque no se muestran datos en la página web y la enumeración de la base de datos se realiza carácter por carácter. Es aplicable cuando la base de datos sólo muestra mensajes de error genéricos, pero el código puede seguir siendo vulnerable. Las inyecciones SQL ciegas requieren algunas técnicas de fuerza bruta e innumerables peticiones; sin embargo, este proceso también puede automatizarse gracias a herramientas como SQLMap. Las inyecciones SQL ciegas se subdividen a su vez en:
- Basada en el contenido. TEl agente de la amenaza formula una serie de preguntas verdaderas o falsas y determina si la afirmación era verdadera o falsa en función de la diferencia en la respuesta de la aplicación.
- Basado en el tiempo. El hacker utiliza diferentes funciones basadas en tiempo de bases de datos SQL para averiguar qué tipo de base de datos se utiliza, ya que diferentes bases de datos utilizan diferentes funciones para las mismas operaciones. Además, utilizando sleep o comandos SQL similares, pueden identificar fácilmente si la consulta es verdadera o falsa: respuesta inmediata – falso; la base de datos responde con el retraso mencionado – verdadero.
Inyecciones SQL fuera de banda
Este tipo de inyección SQL es menos común, ya que depende de la capacidad del servidor para crear peticiones DNS o HTTP para transmitir datos al hacker. Es posible que estas últimas funciones no estén habilitadas en todos los servidores de bases de datos de las aplicaciones, lo que limita el porcentaje de éxito de este intento malicioso.
Las inyecciones SQL fuera de banda se denominan así porque el hacker no puede utilizar el mismo canal para llevar a cabo el ataque. Por ejemplo, cuando la respuesta del servidor es demasiado lenta o inestable, resulta difícil trabajar con SQLi inferencial.
vulnerabilidad
ataque web a
escala mundial
Ejemplo de ataque de inyección SQL
Aunque siempre es una buena idea dotarse de conocimientos teóricos, es aún más beneficioso adquirir experiencia práctica en la cuestión estudiada.
Sin más divagaciones, echemos un vistazo a los conceptos básicos que pueden darle una mejor comprensión de cómo realizar una inyección SQL.
Ejemplos de código SQLi
Los tipos de SQLi son realmente abundantes; sin embargo, los más fáciles y los más populares giran en torno a las manipulaciones con las sentencias UPDATE, INSERT y SELECT, así como con las cláusulas WHERE y ORDER BY.
Los ejemplos siguientes cubren los aspectos básicos y sólo son posibles si no existen controles de seguridad que impidan introducir sintaxis peligrosa en los campos de entrada.
Recuperación de datos con la cláusula WHERE
Supongamos que está navegando por un sitio de comercio electrónico y se detiene en la sección Accesorios. Una URL típica en este caso sería algo así:
https://e-commerce-website.com/products?category=Accessories
Lo que ocurre bajo el capó es ligeramente distinto:
| 1 2 3 | SELECT * FROM products WHERE category = 'Accessories' AND released = 1 |
En este caso, la aplicación web realiza una consulta SQL a la base de datos para mostrar al usuario final sólo los accesorios disponibles. Esta petición puede modificarse fácilmente insertando alguna sintaxis SQL “inteligente”, como guiones dobles, para comentar parte de la consulta y hacerla así irrelevante.
https://insecure-website.com/products?category=Accessories’––
Aquí está el código SQL para la misma consulta:
| 1 2 3 | SELECT * FROM products WHERE category = 'Accessories'--' AND released = 1 |
En este caso, el hacker también puede ver todos los elementos no liberados, ya que la restricción released=1 está desactivada.
Se puede abusar aún más de la vulnerabilidad añadiendo entradas que sean siempre verdaderas, como OR 1=1.
https://insecure-website.com/products?category=Accessories’+OR+1=1––
Lo que recibe la base de datos es lo siguiente:
| 1 2 3 | SELECT * FROM products WHERE category = 'Accessories' OR 1=1--' AND released = 1 |
En el caso anterior, la base de datos devolverá todos los artículos, tanto liberados como no liberados, de todas las demás categorías.
Iniciar sesión sin credenciales
Otro caso de uso de la sintaxis inteligente es obtener acceso a una aplicación disponiendo únicamente de un nombre de usuario. La estrategia es la misma: utilizar la secuencia de doble guión para ocultar parte del código.
Este es el código SQL básico que hace posible el inicio de sesión del usuario:
| 1 2 3 | SELECT * FROM users WHERE username = 'john' AND password = 'johndoe123' |
He aquí la versión inyectada de la misma consulta:
| 1 2 3 | SELECT * FROM users WHERE username = 'administrator'--' AND password = '' |
Si el pirata informático asume que el nombre de usuario es “administrador” o “admin”, lo que todavía puede ser el caso, y utiliza el indicador de comentario SQL antes de la parte de la contraseña de la consulta, puede iniciar sesión como el administrador real o el usuario que casualmente tenía este nombre de usuario.
Lo que es aún más chocante es que en algunos casos ni siquiera se requiere el nombre de usuario.
| 1 2 3 | SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""="" |
Engañando a la aplicación con afirmaciones siempre verdaderas, como que una cadena vacía es siempre igual a otra cadena vacía, el hacker puede iniciar sesión sin ningún tipo de credenciales.
Maximizar los beneficios
En caso de que un SQLi inicial tenga éxito y la aplicación responda con los datos reales de la tabla objetivo, es una oportunidad que los hackers no pueden permitirse perder. Lo más probable es que procedan con un ataque UNION.
Los hackers pueden explotar las capacidades de la palabra clave UNION, como ejecutar una o más consultas SELECT adicionales y añadir los resultados a la consulta original, para acceder a datos de otras tablas.
Un ataque UNION requiere ciertos conocimientos sobre la estructura de la base de datos y otros requisitos previos. Sin embargo, si suponemos que un agente de la amenaza conoce el número de columnas que devuelve la consulta original, el tipo de datos que pueden contener, el nombre de la tabla y sus columnas, puede pasar de esto
| 1 2 3 | SELECT name, description FROM products WHERE category = 'Accessories' |
a este
| 1 2 3 | ' UNION SELECT username, password FROM users--, |
que les permitirá recuperar no sólo los productos y sus descripciones, sino también los respectivos nombres de usuario y contraseñas.
Ejemplos reales de SQLi
Para demostrar que no exageramos la amenaza real de SQLi, hemos recopilado una lista de ataques SQLi bastante recientes y las cuantiosas pérdidas que han sufrido o podrían haber sufrido las empresas víctimas de no ser por los hackers de sombrero blanco.
Filtración de 3,7 millones de contraseñas cifradas
Sencillo hack de Google para encontrar vulnerabilidades en bases de datos
También puede que te preguntes cómo saben los hackers a qué sitio web (de entre casi 2.000 millones) dirigirse para aumentar sus posibilidades de éxito en un ataque SQLi. Pues bien, existe una técnica especial conocida como Google hacking o Google dorking. Esta última se utiliza para recuperar todo tipo de información sensible: desde direcciones de correo electrónico y datos de tarjetas de pago hasta servidores vulnerables y cámaras de Internet expuestas.
El Google hacking nació en 2002, cuando Johnny Long, un reconocido experto en seguridad informática, decidió documentar las consultas avanzadas de búsqueda en Google que revelaban sistemas vulnerables o información sensible. Con el paso de los años, la lista inicial de Google Dorks, es decir, cadenas de búsqueda avanzadas, ha crecido hasta convertirse en toda una base de datos, que ahora mantiene Offensive Security.
Utilizar el hacking de Google para encontrar SQLi es sólo un pequeño subconjunto de lo que puedes hacer con esta técnica de búsqueda avanzada. Y así es como puedes hacerlo.
Digamos que vamos a Google y escribimos algo como esto:
| 1 2 3 | site:com inurl:id "You have an error in your SQL syntax" |
Esta consulta pide al motor de búsqueda que rastree todos los sitios web .com que tengan algún tipo de error de sintaxis en su código SQL. Es probable que esos errores de sintaxis sean inyecciones colocadas a propósito.
Otra cosa que hay que tener en cuenta es que Google no es el único motor que admite la búsqueda avanzada. Puedes obtener los mismos resultados con Bing, Yahoo o DuckDuckGo; la única diferencia radica en la sintaxis del operador de búsqueda, que difiere ligeramente de un motor a otro.
¿Cómo evitar la inyección SQL?
Después de consumir toda esta aterradora información sobre los peligros de SQLi, la pregunta razonable que asalta tu mente es cómo prevenir la inyección SQL. Dado que este ataque existe desde hace tiempo, los expertos en seguridad han aprendido a combatirlo y a preparar las aplicaciones web para el futuro contra los distintos tipos de SQLi.
Aunque cada caso es único y requiere una investigación profesional por parte de consultores de seguridad y pentesters, estas mejores prácticas de seguridad harán el trabajo para la mayoría de las organizaciones y reducirán el riesgo de SQLi considerablemente.
Estas son algunas de las técnicas de prevención de inyecciones SQL más conocidas y que realmente funcionan.
Refactorizar el código heredado
El software heredado es conocido por causar toda una serie de problemas, siendo la seguridad uno de los más perjudiciales.
La razón por la que las aplicaciones heredadas son la fruta más fácil para los piratas informáticos es su incapacidad para integrar controles de seguridad eficaces debido a la incompatibilidad u otras limitaciones técnicas. Por lo tanto, si la aplicación no puede reescribirse por completo y migrarse a la pila moderna, debería considerarse al menos la refactorización parcial de los módulos más vulnerables.
Validación de entradas en el servidor
Cualquier entrada de datos requiere validación para que el usuario pueda acceder o realizar otras acciones. La validación del lado del cliente suele considerarse una comprobación inicial rápida dentro del navegador que permite al usuario darse cuenta rápidamente de cualquier error en la introducción de datos. Ya sea integrada en HTML5 o personalizada con Javascript, la validación del lado del cliente es fácil de eludir y se considera insegura y poco fiable.
Por lo tanto, la validación de entrada fuerte sólo puede hacerse en el lado del servidor. Además, la validación de entrada del lado del servidor se subdivide en allowlist o positiva y blocklist o negativa. La primera se considera más eficaz para combatir SQLi.
Así es como funciona la validación de entrada del lado del servidor allowlist: el servidor sólo acepta los datos que se han definido como buenos y aceptables. Por ejemplo, la verificación de los datos del número de la tarjeta de crédito puede implicar pasos como la comprobación del número esperado de dígitos, la introducción únicamente de datos numéricos y el paso de la fórmula Luhn.
Además, la validación en el servidor debe realizarse tanto a nivel sintáctico (corrección de la fecha, símbolos monetarios) como semántico (validación de la entrada en relación con el contexto empresarial).
Aunque la lista de permisos puede ser bastante completa, la validación de la entrada en el servidor no debe considerarse como la principal medida de seguridad contra SQLi, sino como un paso más en el programa de seguridad multicapa.
Restringir los privilegios de los usuarios de bases de datos
El principio del menor privilegio (POLP) es bien conocido en el ámbito de la seguridad de la información. Y es bastante sencillo: limitar el acceso a la base de datos en función de los roles individuales de los usuarios y de sus funciones cotidianas.
Normalmente, sólo un número limitado de personas necesita crear o borrar algo en la base de datos. Por lo tanto, es vital asegurarse de que la mayoría de los usuarios sólo tengan el acceso de lectura y las vistas parciales de tablas estrictamente necesarias para sus operaciones.
Otro factor crucial a tener en cuenta es que hay que cambiar los privilegios por defecto del SGBD a restringidos, algo que no dará al hacker un control total sobre el sistema incluso en caso de un ataque SQLi exitoso.
En caso de que varias aplicaciones utilicen la misma base de datos, cada una de ellas requiere una cuenta de usuario de base de datos independiente con distintos derechos de acceso. Este enfoque también ayuda a minimizar los daños infligidos por posibles SQLis.
En definitiva, para evitar el efecto bola de nieve cuando el hacker obtiene los derechos de root a través de SQLi, haz que tu política de acceso sea lo más granular posible.
Uso de sentencias preparadas con consultas parametrizadas
Según OWASP, el uso de sentencias preparadas con consultas parametrizadas es la principal defensa contra SQLi. Las sentencias preparadas son tan eficaces contra SQLi porque facilitan que la base de datos distinga claramente entre el código y la entrada proporcionada por el usuario.
Una sentencia preparada típica seguirá un algoritmo sencillo:
- se crea una plantilla de sentencia SQL y se envía a la base de datos
- la consulta SQL se analiza y se comprueba su semántica
- la consulta SQL se compila con texto de marcador de posición (vinculación)
- los marcadores de posición se sustituyen por los datos introducidos por el usuario
- la consulta se almacena en la caché
- la base de datos ejecuta la sentencia
Como se desprende de estos pasos, los datos proporcionados por el usuario no pueden afectar a la intención de una consulta, ya que están separados del código ejecutable y siempre se interpretarán como una simple cadena.
Aquí surge otra pregunta: Si las sentencias preparadas son tan seguras, ¿por qué seguimos teniendo tantos incidentes SQLi? La cuestión es que, en ciertos casos, las sentencias preparadas pueden afectar negativamente al rendimiento de la aplicación, razón por la cual los desarrolladores optan por no utilizarlas y recurrir a otras técnicas de seguridad menos eficaces.
Implementación correcta de procedimientos almacenados
Un procedimiento almacenado es un código SQL preparado que puede guardarse y utilizarse varias veces en el futuro. La diferencia entre un procedimiento almacenado y una sentencia preparada es que el código SQL del primero se define y almacena en la propia base de datos: cuando hay que ejecutar la consulta, simplemente se llama desde la aplicación.
Los procedimientos almacenados se consideran tan eficaces como las sentencias preparadas siempre que se implementen de forma segura. De lo contrario, también son vulnerables a SQLi.
Los desarrolladores deben tener cuidado de no incluir SQL dinámico inseguro dentro del procedimiento almacenado. Si es totalmente inevitable generar un SQL dinámico dentro de un procedimiento almacenado, aconsejamos parametrizar las consultas dentro del procedimiento almacenado en lugar de concatenar los parámetros.
Escape de todas las entradas suministradas por el usuario
Este enfoque es un remedio bastante desesperado: sólo debe utilizarse si no es posible hacer nada más. Un caso de uso típico sería proteger software heredado y disponer de un presupuesto limitado para una validación de entrada completa.
La función de escape codifica los caracteres especiales, como “/”, “?” o “$”, para que la base de datos no confunda la entrada proporcionada por el usuario con el código del desarrollador.
Aunque cada DBMS tiene su propio esquema de escape, el propósito es el mismo: evitar que la entrada proporcionada por el usuario se interprete como un comando ejecutable.
Una vez más, esta técnica no puede garantizar una protección del 100% contra SQLi. Lo ideal sería reescribir la aplicación desde cero utilizando consultas parametrizadas o procedimientos almacenados.
Otro método de escape es la codificación hexadecimal de toda la entrada proporcionada por el usuario. Este escenario presupone codificar no sólo los caracteres especiales, sino todos los caracteres de la entrada antes de incluirlos en la consulta SQL.
Ocultar errores de la base de datos
Lo que causó el error en la base de datos es muy útil para el desarrollador, pero no para el usuario final. Es vital asegurarse de que los mensajes de error no revelen ninguna información sensible que pueda utilizar un pirata informático.
Por ejemplo, en lugar de mostrar la sentencia SQL que revela dónde se ha producido exactamente el error, muestre mensajes emergentes genéricos orientados al cliente del tipo: “Lo sentimos, estamos experimentando problemas técnicos. Vuelva a intentarlo más tarde”.
Cifrar datos confidenciales
Dejar datos altamente confidenciales en texto plano nunca es una buena idea. Esta es la razón por la que tantas empresas, especialmente en los sectores de la tecnología financiera, la sanidad y los medios de comunicación, han integrado el cifrado de datos en sus sistemas: el coste de la exposición de datos es demasiado alto (unos 4 millones de dólares de media).
Otro factor crítico a tener en cuenta es que el cifrado por sí solo no es una solución milagrosa. Supongamos que una empresa ha implementado el cifrado de contraseñas, lo que significa que las contraseñas reales nunca se almacenan, sólo sus equivalentes cifrados. Sin embargo, si los usuarios no se han molestado en crear contraseñas seguras, como suele ser el caso, sus credenciales pueden verse fácilmente comprometidas con tablas hash o rainbow que pueden asignar claves a valores.
El salado de los hashes cifrados proporcionaría una capa de seguridad adicional. En términos sencillos, el salado consiste en añadir un dato aleatorio a la contraseña antes de convertirla en hash. Las contraseñas con sal reducen la probabilidad de que se encuentren contraseñas de usuario débiles en una tabla hash.
Realice una inspección periódica del Código
SQLi es a menudo el resultado de malas prácticas de desarrollo de software. Por lo tanto, es razonable iniciar el plan de prevención desde el código fuente, dejando que expertos en seguridad externos realicen una auditoría imparcial del código.
Igualmente importante es llevar a cabo pruebas de penetración regulares para detectar señales de alarma y detectar las vulnerabilidades supervisadas por escáneres y fuzzers. Para un experto en pruebas de penetración, descubrir una vulnerabilidad SQLi es tarea fácil; además, puede explicar el resultado de otros exploits potenciales o existentes y ofrecer un plan de corrección de inyecciones SQL que se ajuste al statu quo de la empresa.
Resumen
La inyección SQL es una vulnerabilidad tan antigua que da vergüenza saber que sigue siendo una amenaza para los sitios web y las aplicaciones modernas. Es muy popular debido a su implementación relativamente fácil, la prevalencia de los SGBD SQL y el inmenso valor de los datos empresariales. La buena noticia es que se puede prevenir. Todo lo que se necesita es alinear sus esfuerzos de ingeniería con las últimas prácticas de seguridad, supervisión e inspección continuas, y pruebas independientes de inyección sql para cerrar cualquier brecha restante.
¿Cuál es su experiencia en la lucha contra SQLi? Nos encantaría conocerla; ¡compártala por correo electrónico o en los comentarios!