Seguridad de bases de datos

Digital by admin

Cómo evitar las inyecciones SQL y protegerse de ellas

Declaración oficial: ¡Estimados lectores! Este artículo tiene un propósito puramente informativo. ¡IGIS Labs no promueve la realización de ningún tipo de ciberataques! Recuerde que llevar a cabo cualquier ataque hacker es un delito punible por ley y será perseguido legalmente.
SQL inyeccion

Inyección SQL (SQLi) es una vulnerabilidad en la seguridad de las aplicaciones web mediante la cual un atacante puede interferir con las consultas que la aplicación envía a su base de datos. Esto abre la posibilidad de ver datos a los que normalmente no se tiene acceso, incluida información de otros usuarios o cualquier dato disponible para la aplicación. Frecuentemente, el atacante puede modificar o eliminar esta información, alterando constantemente el contenido o el comportamiento de la aplicación.

En ciertas situaciones, un ataque de inyección SQL puede ser potenciado, permitiendo al atacante comprometer el servidor principal u otra infraestructura en el backend. También puede servir como base para ataques de tipo “denegación de servicio.
Un ataque exitoso de inyección SQL puede resultar en acceso no autorizado a datos sensibles, incluyendo contraseñas, información de tarjetas de crédito o datos personales de usuarios. Se conocen casos de uso de inyecciones SQL en grandes fugas de datos, lo que ha causado daño a la reputación y multas por parte de reguladores. En algunos casos, el atacante puede crear un punto de acceso oculto y permanente en los sistemas de la organización, lo que conduce a una comprometida a largo plazo que pasa desapercibida durante mucho tiempo.

Aquí están los ejemplos conocidos de ciberataques utilizando inyecciones SQL:

  1. Ataque GhostShell: Hackers del grupo APT Team GhostShell atacaron 53 universidades utilizando inyecciones SQL. Como resultado, se sustrajeron y publicaron 36,000 registros personales de estudiantes, profesores y empleados.
  2.  Ataque al gobierno de Turquía: Otro grupo APT, conocido como RedHack, aprovechó las inyecciones SQL para hackear el sitio web del gobierno turco y borrar las deudas de las organizaciones estatales.
  3. Fuga de datos en 7-Eleven: Un grupo de delincuentes utilizó inyecciones SQL para infiltrarse en los sistemas corporativos de la cadena minorista 7-Eleven, lo que resultó en el robo de datos de 130 millones de tarjetas de crédito.
  4. Fuga de datos de HBGary: Hackers asociados al grupo activista Anonymous utilizaron inyecciones SQL para atacar el sitio web de la empresa de seguridad informática HBGary. Este incidente fue una respuesta a la divulgación de información sobre miembros de Anonymous por parte del CEO de HBGary.

A pesar de su antigüedad, este tipo de ataques aún mantiene su relevancia. Y eso demuestra la estadística de ciberataques del 2022:

vulnerabilidades 2023

Cómo detectar las inyecciones SQL?

Usando un conjunto sistemático de verificaciones en cada punto de entrada de la aplicación, es posible identificar manualmente posibles inyecciones SQL. Para ello, se suelen emplear las siguientes metodologías:

  1. Introducir el carácter de comilla simple ‘ y analizar los errores u otras anomalías recibidas en la respuesta.
  2. Aplicar sintaxis SQL que evalúe un valor base de entrada y otro valor, para detectar discrepancias en las respuestas del sistema.
  3. Crear condiciones lógicas tipo OR 1=1 y OR 1=2, y observar las diferencias en las respuestas de la aplicación.
  4. Enviar datos (cargas útiles) que causen retardos en la ejecución de la consulta SQL, y analizar el tiempo necesario para obtener una respuesta.
  5. Enviar datos OAST (PSAFB – Pruebas de Seguridad de Aplicaciones Fuera de Banda) que interactúen con una red externa al ejecutar una consulta SQL, y luego rastrear esas interacciones.

Estos métodos ayudan a identificar vulnerabilidades en la aplicación, permitiendo que los desarrolladores tomen medidas para prevenir las inyecciones SQL.

Es importante recordar que las inyecciones SQL no se limitan solo a las cláusulas WHERE en las consultas SELECT; también pueden ocurrir en otras partes de la consulta. Lugares comunes donde pueden ocurrir las inyecciones SQL son:

  • En las operaciones UPDATE, tanto en los valores a actualizar como en la cláusula WHERE.
  • En las operaciones INSERT, en los valores que se insertan.
  • En las operaciones SELECT, tanto en el nombre de la tabla como en la columna.
  • En las operaciones SELECT, en la cláusula ORDER BY.

Aunque los probadores experimentados suelen estar familiarizados con las variantes clásicas de inyecciones SQL en las cláusulas WHERE de las consultas SELECT, es importante recordar que las vulnerabilidades pueden manifestarse en otras partes y tipos de consultas. Detectar y abordar estas vulnerabilidades requiere un análisis más profundo y amplio de todo el código SQL de la aplicación.
Existen numerosos ejemplos de vulnerabilidades, ataques y técnicas de inyección SQL que ocurren en diversos contextos. Algunos escenarios comunes de inyección SQL incluyen:

1. Obtención de datos ocultos al modificar la consulta SQL para mostrar resultados adicionales.
2. Manipulación de la lógica de la aplicación al alterar la consulta para modificar el funcionamiento del programa.
3. Ataques tipo UNION que permiten extraer datos de diferentes tablas de la base de datos.
4. Inyecciones SQL ciegas, cuando los resultados de tu consulta no se reflejan en las respuestas de la aplicación.

Estos métodos permiten a los atacantes acceder a datos o alterar el funcionamiento de la aplicación manipulando consultas SQL. Comprender estos tipos de ataques ayuda a los desarrolladores a tomar medidas para garantizar la seguridad y protegerse contra estas vulnerabilidades.
Por ejemplo, cuando la entrada del usuario se puede manipular para modificar las consultas SQL y obtener resultados adicionales, eso demuestra casos típicos de inyección SQL. Supongamos que hay una tienda en línea con la siguiente URL:

`https://soloejemplo.ejemplo/productos?category=Regalos’–`
Consulta modificada: `SELECT * FROM productos WHERE category = ‘Regalos’–‘ AND released = 1`
‘–‘ como un comentario en SQL anula el resto de la consulta, evitando la comprobación de released = 1. Como resultado, se muestran todos los productos, incluidos los ocultos.

URL: `https://soloejemplo.ejemplo/productos?category=Regalos’+OR+1=1–`
Consulta modificada: `SELECT * FROM productos WHERE category = ‘Regalos’ OR 1=1–‘ AND released = 1`

La inserción de ‘OR 1=1‘ siempre es verdadera, extrayendo todos los productos sin importar la categoría o el estado.
Estos ataques muestran los riesgos de una validación de entrada insuficiente, permitiendo a los atacantes manipular consultas y obtener acceso no autorizado a los datos. Implementar medidas como consultas parametrizadas o validación de entrada puede prevenir vulnerabilidades de inyección SQL. 

Otro ejemplo. Imagina una aplicación que permite a los usuarios iniciar sesión usando un nombre de usuario y contraseña. Si un usuario envía el nombre de usuario “david” y la contraseña “jasper”, la aplicación verifica las credenciales ejecutando la siguiente consulta SQL:
SELECT * FROM users WHERE username = ‘david’ AND password = ‘jasper’
Si la consulta devuelve los datos del usuario, el inicio de sesión es exitoso; de lo contrario, es rechazado.

En este caso, un atacante puede iniciar sesión como cualquier usuario sin proporcionar una contraseña. Esto es posible gracias a la secuencia de comentarios SQL –, que elimina la verificación de la contraseña de la consulta. Por ejemplo, al enviar el nombre de usuario `administrator’–` y dejar el campo de la contraseña vacío, la consulta devolverá el usuario `administrator`, autenticando exitosamente al atacante:
SELECT * FROM users WHERE username = ‘administrator’–‘ AND password = ””

  1. Es importante considerar las inyecciones ciegas como una variante particularmente poderosa de las inyecciones. Aquí hay algunos enfoques para explotar las inyecciones SQL ciegas, y la elección del método depende del tipo de vulnerabilidad y la base de datos utilizada:
    Modificar la lógica de la consulta para crear diferencias notables en las respuestas de la aplicación según la veracidad de una condición. Esto puede incluir la inserción de nuevas condiciones en la lógica de los operadores o la llamada condicional a un error, como la división por cero, para rastrear cambios en las respuestas.
  2. Llamar condicionalmente a retrasos temporales durante la ejecución de la consulta. Esto permite inferir la veracidad de una condición según el tiempo que tarda la aplicación en procesar la respuesta.
  3. Iniciar interacciones de red externas utilizando métodos OAST. Esta técnica es extremadamente poderosa y funciona donde otros métodos son ineficaces. A menudo, esto permite exportar datos directamente a través de un canal externo, por ejemplo, inyectando datos en consultas DNS a un dominio controlado.

Estos métodos otorgan a los atacantes la capacidad de extraer información, incluso si no obtienen respuestas directas de las consultas, proporcionando métodos alternativos para extraer datos a través de manipulaciones hábiles o influencias indirectas en el entorno de la aplicación.
Las inyecciones SQL también pueden dividirse en inyecciones de primer y segundo orden.
La inyección SQL de primer orden ocurre cuando la aplicación maneja la entrada del usuario desde una solicitud HTTP e incluye esa entrada en una consulta SQL sin garantizar la seguridad adecuada.
La inyección SQL de segundo orden ocurre cuando una aplicación recibe la entrada del usuario a través de una solicitud HTTP y la guarda para usarla más adelante. Por lo general, esto se hace almacenando la entrada en una base de datos, pero la vulnerabilidad no se manifiesta al momento de guardar los datos. Más tarde, al procesar otra solicitud HTTP, la aplicación extrae los datos guardados y los incluye en una consulta SQL sin asegurar su seguridad. Es por esto que la inyección SQL de segundo orden también se conoce como inyección SQL almacenada.

Los métodos de detección y explotación de las inyecciones SQL a menudo comparten enfoques similares en diferentes bases de datos, ya que las funciones principales de SQL se implementan de manera similar. Sin embargo, entre las bases de datos comunes, existen diferencias que afectan la aplicación de métodos de detección y explotación de inyecciones SQL en diferentes plataformas. Esto se refleja en:

  • Las formas de concatenar cadenas.
  • El manejo de comentarios.
  • La ejecución de consultas batch (o en bloque).
  • Las API específicas de la plataforma.
  • Los tipos de mensajes de error.

Una vez que se detecta una vulnerabilidad de inyección SQL, a menudo es útil obtener información adicional sobre la base de datos, lo que puede ayudar en la explotación posterior de la vulnerabilidad.
Puede solicitar detalles sobre la versión de la base de datos. Se aplican diferentes métodos a diferentes tipos de bases de datos. Por ejemplo, para Oracle, puede ejecutar la siguiente consulta:

SELECT * FROM v$version

También es posible identificar las tablas existentes en la base de datos y sus columnas. Por ejemplo, en la mayoría de las plataformas, puede ejecutar la siguiente consulta para listar las tablas:

SELECT * FROM information_schema.tables

Las inyecciones SQL pueden ocurrir no solo en cadenas de consulta. Las entradas interpretadas como consultas SQL, como en formatos JSON o XML, también son vulnerables. Estos formatos pueden proporcionar métodos alternativos para evadir los mecanismos de protección, como WAF, a través de la codificación o el escapado de caracteres en palabras clave prohibidas.
Los diferentes métodos de protección contra las inyecciones SQL ayudan a prevenir vulnerabilidades mediante enfoques y mecanismos diversos. Proporcionan una defensa sólida contra posibles ataques y explotaciones de vulnerabilidades.


El primer método es el uso de sentencias preparadas, que ofrecen una clara separación entre el código y los datos, eliminando problemas de inyección SQL. Estas permiten evitar la interpretación de entradas maliciosas como parte del código SQL.


El segundo método, las stored procedures (procedimientos almacenados), utiliza enfoques similares a las sentencias preparadas para proporcionar seguridad. Sin embargo, se debe tener cuidado, ya que algunos escenarios, como la construcción dinámica de consultas SQL o los privilegios del propietario de la base de datos, pueden representar una amenaza para la seguridad.

La validación basada en listas blancas es el tercer método de protección, que verifica que la entrada del usuario se ajuste a los valores conocidos y permitidos, evitando la inclusión de datos inseguros en las consultas.
Finalmente, la cuarta técnica es la sanitización de entradas, utilizando caracteres de escape para ignorar ciertos caracteres de control. Esta técnica es la menos segura y se recomienda como último recurso debido a su eficacia limitada.
Todas estas estrategias ofrecen diferentes enfoques para protegerse de las inyecciones SQL. No obstante, se recomienda el uso de sentencias preparadas o ‘stored procedures’, ya que proporcionan una protección más efectiva y confiable contra posibles ataques.
Las vulnerabilidades de inyección SQL siguen siendo relevantes a pesar de su larga historia, y requieren que los desarrolladores aborden de manera responsable la protección de sus recursos de información (bases de datos, sitios web, aplicaciones web, etc.).

IGIS Labs siempre está listo para ofrecer a sus clientes un servicio de auditoría de ciberseguridad de alta calidad. ¡Sabemos cómo protegerlos!