Universidad continental
Facultada de derecho
Escuela profesional de derecho
Trabajo de investigación
BASES DE DATOS NO RELACIONALES: QUÉ SON, SUS DIFERENCIAS CON
LAS BASES RELACIONALES Y SUS PRINCIPALES EJEMPLOSInyección SQL
(SQLi): Análisis de Vulnerabilidad, Taxonomía de Ataque y Estrategias de Mitigación
bajo Estándares OWASP
Línea de investigación: Estado Constitucional: Derecho Informático
Presentado por:
DIEGO ALEJANDRO CARRILLO
SEGUNDO
Código ORCID: [Link]
0006-0173-1405
JORGE PRADA JAVIER
Código ORCID:
CUSCO – PERÚ
2025
3
ÍNDICE
1.1 Definición Formal de Inyección SQL (SQLi) 1
1.2 Importancia y Alcance de la Amenaza 1
2.1 El Fallo Fundamental: El Uso de Consultas Dinámicas (Concatenación) 2
2.2 Consecuencias Agravadas: Robo de Credenciales y Movimiento Lateral 2
2.3 Defensas Secundarias y Desaconsejadas 3
Referencias 5
4
AGRADECIMIENTOS
Quiero expresar mi agradecimiento por el excelente trabajo. Es un gran aporte.
5
RESUMEN
La recomendación técnica más importante de la comunidad de seguridad,
encabezada por la Fundación OWASP, para reducir este riesgo es aplicar rigurosamente
las sentencias preparadas (consultas parametrizadas). Esta técnica garantiza que el
motor de la base de datos siempre separe el código SQL y los datos proporcionados por
el usuario, lo que limita la habilidad del atacante para modificar la intención de la
consulta. La inyección SQL (SQLi) es una de las debilidades de seguridad más viejas y
persistentes en las aplicaciones web. Esta sigue siendo clasificada como uno de los
métodos de ataque más comunes entre los ciberdelincuentes (INCIBE, s. f.). Esta
agresión aprovecha el principio de la composición de consultas dinámicas, lo que
posibilita a los actores maliciosos llevar a cabo órdenes SQL no permitidas directamente
en la base de datos de la víctima. Si la explotación tiene éxito, puede resultar en el
hurto de credenciales, la alteración o eliminación de datos esenciales y la elevación de
privilegios a nivel del sistema operativo, lo que simplifica el movimiento lateral dentro
de la infraestructura del perjudicado. En ataques de tipo OOB (Out-of-Band),
Inferencial (ciegos) y In-Band, se puede observar la amenaza. En Latinoamérica, el
costo medio de una violación de datos llegó a 2,46 millones de dólares en 2023 (IBM,
2023), lo que demuestra el impacto financiero relevante de estas filtraciones.
1
1.1 Definición Formal de Inyección SQL (SQLi)
La Inyección SQL (SQLi) es una vulnerabilidad de seguridad web que posibilita
a un atacante interferir con las consultas que una aplicación hace a su base de datos, lo
cual tiene el potencial de alterar o manipular los datos internos. La inyección de código
SQL no autorizado es el mecanismo principal del ataque. Este código se inserta por
medio de datos de entrada que han sido manipulados maliciosamente (como parámetros
de URL o campos de formularios) y que una aplicación no consigue validar o limpiar
adecuadamente. El motor de la base de datos considera la entrada del usuario como una
ampliación de su propio código ejecutable cuando la aplicación emplea esta entrada
modificada para crear una consulta dinámica. En el contexto de los riesgos cibernéticos,
esta amenaza sigue siendo muy relevante, aunque se han logrado avances en la
programación segura, la inyección SQL persiste como una vía principal de explotación;
es por eso que las agencias de ciberseguridad lo consideran uno de los vectores de
ataque más comunes, ya que los ciberdelincuentes buscan fallos en la configuración o
defectos del sistema para introducir su carga maliciosa.
1.2 Importancia y Alcance de la Amenaza
Las implicaciones de una Inyección SQL exitosa van más allá de la mera
interrupción del servicio. Un atacante tiene la capacidad de llevar a cabo una serie de
acciones maliciosas, entre las cuales se encuentran: acceder a información confidencial
(como datos de clientes o secretos empresariales), alterar o borrar datos existentes (lo
que puede provocar daños operativos o corrupción) y, en el caso de que los privilegios
sean elevados, tomar control total sobre la aplicación.
Al contemplar cómo la SQLi sirve como punto de partida para ataques más
sofisticados, la inquietud se agrava. La vulnerabilidad puede superar el ámbito de
control de la base de datos; se ha comprobado que la inyección SQL es capaz de otorgar
a los atacantes acceso a privilegios del sistema operativo (OS). El acceso al sistema
2
operativo es esencial ya que permite la movilidad lateral dentro de la infraestructura de
la aplicación. Esto implica que el ataque se transforma en un vector de acceso primario,
lo cual posibilita que los delincuentes virtuales trasladen a otros sistemas delicados
dentro de la red, como por ejemplo los sistemas financieros o bases de datos extra sobre
clientes. Por ende, una vulnerabilidad de SQLi que asciende a privilegios de OS tiene el
potencial de convertir una fuga de datos ordinaria en un compromiso sistémico que
permite la instalación de malware o el aumento de las amenazas que tienen un gran
impacto, como el ransomware. Esta intensificación del riesgo resalta que la inyección
SQL debería ser considerada no únicamente como un error en la validación de datos,
sino también como una vía crítica para la exfiltración y persistencia a gran escala.
1.1 El Fallo Fundamental: El Uso de Consultas Dinámicas (Concatenación)
El ataque de inyección SQL se logra fundamentalmente cuando una aplicación
no realiza una validación correcta de los datos suministrados por fuentes no confiables
antes de utilizarlos para construir una consulta dinámica a la base de datos y el núcleo
del problema es la concatenación de cadenas, donde la entrada del usuario se une
directamente a la sentencia SQL, ya que si un atacante altera intencionalmente su
entrada para incluir comandos SQL, la base de datos los interpretará y ejecutará como si
fueran parte de la lógica legítima de la aplicación.
1.2 Consecuencias Agravadas: Robo de Credenciales y Movimiento Lateral
La explotación de SQLi permite a los atacantes robar credenciales de usuario,
incluyendo nombres de usuario y contraseñas. Con esta información, quienes perpetran
los ataques pueden hacerse pasar por otros, usar sus privilegios para operar en la
aplicación, llevar a cabo acciones financieras no autorizadas (como hacer transferencias
de fondos) o cambiar pormenores de cuentas con mala intención. La inyección SQL,
además de robar datos de forma directa, se utiliza como vector para la difusión de
amenazas internas. Este proceso queda evidenciado con el caso de la brecha de
3
Heartland Payment Systems en 2008, uno de los sucesos más destacados de inyección
SQL. Los atacantes emplearon SQLi para conseguir un punto de apoyo inicial en la red
empresarial de Heartland. Una vez que entraron, pusieron malware diseñado para
capturar datos sensibles de tarjetas a medida que estos transitaban por la red. Este
enfoque, descrito como "lento y sostenido" (low and slow approach), permitió el robo
masivo de datos durante un período prolongado sin ser detectado, es por ello que la
capacidad de la SQLi para escalar el acceso y facilitar la instalación de código malicioso
para el robo sostenido demuestra que la seguridad debe enfocarse no solo en prevenir la
inyección inicial, sino también en el monitoreo y detección de comportamientos
anómalos post-explotación para limitar la ventana de tiempo del compromiso.
1.3 Defensas Secundarias y Desaconsejadas
2.3.1. Validación de Entrada de Lista Blanca (Allow-list).- Esta técnica se
recomienda como defensa secundaria para detectar entradas no autorizadas antes de que
lleguen a la capa de base de datos. Implica asegurarse de que la entrada solo contenga
caracteres o patrones de un conjunto previamente definido como seguro. Esta validación
solo se considera una defensa primaria en situaciones extremadamente raras donde la
parametrización es imposible (por ejemplo, para nombres de tablas), pero en general, se
utiliza como una capa de higiene de datos previa a la ejecución de la consulta.
2.3.2. Escapar la Entrada (Práctica Desaconsejada).- La técnica de escapar
caracteres (o escape characters) es la Opción 4 en la jerarquía de defensa de OWASP y
está FUERTEMENTE DESACONSEJADA. Esta medida es inherentemente frágil
porque depende del motor de base de datos específico y no es efectiva para evitar todas
las formas de inyección, siendo posible que un atacante encuentre una forma de eludir
esta sanitización. El análisis técnico concluye que la prevención de SQLi requiere la
aplicación de una estrategia de defensa en profundidad. La Consulta Parametrizada debe
4
ser el control principal para la prevención de la vulnerabilidad; sin embargo, si la
aplicación falla, los controles de contención como el Mínimo Privilegio deben estar
implementados para limitar severamente el daño potencial de la explotación.
Referencias
Acunetix. (s. f.). Types of SQL Injection (SQLi). Consultado el 2024, 15 de junio.
[Link]
5
Gigamon. (2025, 12 de marzo). 2009: The Heartland Breach: A Cybersecurity Wake-Up
Call and the Evolution of Network Visibility. Blog de Gigamon.
[Link]
wake-up-call-and-the-evolution-of-network-visibility/
IBM. (2023, 23 de agosto). El costo promedio de una filtración de datos en
Latinoamérica alcanzó USD 2,46 millones en 2023. IBM Newsroom.
[Link]
de-datos-en-Latinoamerica-alcanzo-USD-2,46-millones-en-2023