15. Inyección SQL, NoSQL, comandos y técnicas de validación segura

15.1 Introducción

Una inyección aparece cuando una aplicación toma una entrada controlable por el usuario y la incorpora de forma insegura en una consulta, comando, expresión o estructura interpretada por otro componente.

Las inyecciones siguen siendo relevantes porque conectan entradas externas con sistemas sensibles: bases de datos, shells, motores de plantillas, directorios LDAP, parsers XML, consultas NoSQL y servicios internos.

En este tema veremos cómo reconocer, analizar y validar inyecciones SQL, NoSQL y de comandos, siempre con técnicas controladas que eviten extracción masiva, modificación de datos o interrupción de servicios.

15.2 Qué tienen en común las inyecciones

Todas las inyecciones comparten un patrón: la aplicación mezcla datos con instrucciones. El sistema receptor interpreta una parte de la entrada como lógica, no solo como valor.

• El usuario controla un parámetro, cabecera, cookie, cuerpo o archivo.
• La aplicación no separa correctamente datos e instrucciones.
• El backend interpreta caracteres especiales, operadores o sintaxis.
• El resultado altera la consulta, comando o expresión original.
• El impacto depende de permisos, contexto y datos accesibles.

15.3 Superficies de entrada

Las inyecciones no aparecen solo en formularios visibles. Cualquier dato procesado por el servidor puede ser una superficie de entrada.

15.4 Inyección SQL

La inyección SQL ocurre cuando una entrada altera una consulta SQL. Puede afectar búsquedas, filtros, login, reportes, APIs, paneles administrativos o cualquier función que consulte una base relacional.

Impactos posibles:

• Bypass de autenticación.
• Lectura de datos no autorizados.
• Modificación o eliminación de registros.
• Enumeración de estructura de base de datos.
• Ejecución de funciones peligrosas según motor y permisos.
• Escalada hacia otros sistemas mediante credenciales almacenadas.

La severidad depende de permisos de la cuenta de base de datos, exposición de la aplicación y datos accesibles.

15.5 Tipos de SQLi

15.6 Señales de posible SQLi

No todas las señales confirman vulnerabilidad, pero ayudan a construir hipótesis.

• Errores de base de datos visibles.
• Diferencias de respuesta al introducir caracteres especiales.
• Cambios anómalos en cantidad de resultados.
• Retrasos consistentes ante entradas específicas.
• Filtros que aceptan operadores inesperados.
• Mensajes que revelan nombres de tablas, columnas o motores.
• Comportamiento distinto entre parámetros aparentemente similares.

15.7 Validación segura de SQLi

La validación debe demostrar que la entrada altera la consulta sin extraer datos reales innecesarios.

• Comparar respuestas con condiciones verdaderas y falsas controladas.
• Usar registros de prueba cuando sea posible.
• Evitar consultas que enumeren tablas completas.
• Evitar modificar o borrar datos.
• Usar retrasos mínimos en pruebas time-based.
• Capturar fragmentos de error o diferencias de respuesta.
• Detenerse cuando la evidencia demuestre el comportamiento vulnerable.

15.8 Inyección NoSQL

La inyección NoSQL ocurre cuando entradas no confiables alteran consultas en bases no relacionales, como MongoDB, CouchDB u otros motores. Puede aparecer especialmente en APIs JSON y filtros dinámicos.

Riesgos comunes:

• Bypass de autenticación por operadores inesperados.
• Consulta de documentos fuera de permisos.
• Alteración de filtros de búsqueda.
• Acceso a campos no previstos.
• Abuso de consultas flexibles sin validación de esquema.

En NoSQL, el problema muchas veces no es un carácter especial, sino aceptar estructuras u operadores que el usuario no debería controlar.

15.9 Señales de NoSQLi

15.10 Validación segura de NoSQLi

La validación segura de NoSQLi se basa en confirmar que el servidor acepta estructuras u operadores no esperados.

• Trabajar con cuentas de laboratorio.
• Enviar objetos o tipos inesperados de forma controlada.
• Comparar respuestas entre valores normales y valores alterados.
• No enumerar colecciones completas.
• No intentar bypass de cuentas reales.
• Registrar petición, respuesta y diferencia de comportamiento.

15.11 Inyección de comandos

La inyección de comandos ocurre cuando una entrada del usuario se incorpora a un comando del sistema operativo. Es especialmente grave porque puede permitir ejecutar acciones en el servidor con los permisos del proceso vulnerable.

Puede aparecer en funciones como:

• Diagnóstico de red: ping, traceroute, nslookup.
• Conversión de archivos.
• Compresión o descompresión.
• Procesamiento de imágenes o documentos.
• Backups o tareas administrativas.
• Integraciones con scripts del sistema.

15.12 Señales de inyección de comandos

• La aplicación devuelve salida de comandos del sistema.
• Errores mencionan shell, rutas o binarios.
• Caracteres de separación alteran el comportamiento.
• Retrasos consistentes ante entradas que provocan espera.
• Conexiones salientes hacia un endpoint controlado.
• Diferencias entre sistemas Linux y Windows según entrada.

La ausencia de salida visible no descarta la vulnerabilidad. Puede existir una inyección ciega que solo se observe por tiempo o interacción externa controlada.

15.13 Validación segura de command injection

La validación debe confirmar ejecución sin cambiar el sistema.

15.14 Inyección LDAP

LDAP se usa para consultar directorios, usuarios y grupos. Una inyección LDAP ocurre cuando entradas no confiables alteran filtros de búsqueda o autenticación.

Riesgos posibles:

• Bypass de autenticación.
• Enumeración de usuarios.
• Acceso a atributos no esperados.
• Alteración de filtros de búsqueda.
• Divulgación de estructura del directorio.

La validación debe evitar enumerar directorios completos y usar cuentas o datos de prueba cuando sea posible.

15.15 Inyección en plantillas

Server-Side Template Injection ocurre cuando una entrada llega a un motor de plantillas y se interpreta como expresión. Puede variar desde lectura de variables hasta ejecución de código, según motor y configuración.

• Señales de evaluación de expresiones matemáticas o variables.
• Errores que revelan motor de plantilla.
• Diferencias entre contenido mostrado y contenido interpretado.
• Contextos donde el usuario personaliza mensajes, plantillas o vistas.

La validación segura debe limitarse a expresiones inocuas y no intentar acceso a objetos internos sensibles sin autorización.

15.16 Inyección XML y XXE

Cuando una aplicación procesa XML, pueden aparecer riesgos como entidades externas, expansión excesiva o lectura de recursos internos. XXE ocurre cuando el parser permite entidades externas inseguras.

Validación segura:

• Confirmar si el parser acepta entidades externas usando endpoint controlado.
• No leer archivos sensibles del servidor.
• No provocar expansión masiva de entidades.
• Registrar petición y respuesta mínima.
• Verificar configuración del parser si el cliente provee acceso.

15.17 Inyecciones ciegas

Una inyección ciega no muestra el resultado directamente. Se detecta por diferencias de tiempo, comportamiento, errores indirectos o interacción con un recurso controlado.

• Time-based: la respuesta tarda más cuando la condición se cumple.
• Boolean-based: cambia el contenido o estado de la respuesta.
• Out-of-band: el servidor realiza una consulta o conexión externa observable.

Estas pruebas deben ser especialmente cuidadosas para no generar carga, bucles o conexiones no autorizadas.

15.18 Evitar daño durante validación

Las inyecciones pueden tener impacto alto. La validación debe evitar acciones destructivas.

• No modificar datos de producción.
• No borrar registros.
• No extraer tablas completas.
• No ejecutar comandos persistentes.
• No descargar herramientas externas al servidor.
• No consultar servicios internos fuera de alcance.
• Usar delays cortos y limitados en pruebas de tiempo.
• Detenerse cuando la evidencia sea suficiente.

15.19 Prevención de SQLi

La prevención de inyección SQL se basa en separar datos de instrucciones y limitar impacto si algo falla.

• Consultas parametrizadas o prepared statements.
• ORM usado correctamente, sin concatenación insegura.
• Validación de tipos, formatos y rangos.
• Principio de mínimo privilegio en cuentas de base de datos.
• Errores genéricos para usuarios y logs detallados protegidos.
• Revisión de consultas dinámicas.
• Pruebas automatizadas de seguridad en rutas críticas.

15.20 Prevención de NoSQLi

En NoSQL, la prevención depende de validar estructura, tipos y operadores aceptados.

• Validar esquemas de JSON de entrada.
• Rechazar objetos donde se esperan cadenas o números.
• No permitir operadores de consulta desde entrada directa.
• Usar APIs seguras del driver.
• Aplicar listas permitidas de campos filtrables.
• Limitar permisos de la cuenta usada por la aplicación.
• Registrar intentos con estructuras inesperadas.

15.21 Prevención de command injection

La mejor prevención es evitar invocar comandos del sistema con entrada de usuario. Si no hay alternativa, deben aplicarse controles estrictos.

• Usar APIs nativas en lugar de shell.
• Separar argumentos en llamadas seguras, sin concatenar cadenas.
• Aplicar listas permitidas de valores.
• Validar tipos, longitud y caracteres permitidos.
• Ejecutar procesos con privilegios mínimos.
• Evitar interpretar metacaracteres de shell.
• Registrar y alertar entradas anómalas.

15.22 Evidencia en hallazgos de inyección

La evidencia debe mostrar la diferencia entre entrada normal y entrada manipulada, sin revelar datos sensibles innecesarios.

15.23 Errores frecuentes

• Probar inyecciones solo en parámetros visibles y olvidar JSON, cookies o cabeceras.
• Extraer datos reales cuando una prueba controlada era suficiente.
• Usar delays largos que afectan disponibilidad.
• Confundir error con impacto explotable.
• No validar si la cuenta de base tiene permisos limitados.
• Probar command injection con comandos que modifican el sistema.
• Depender solo de herramientas automáticas.
• No documentar entrada normal, entrada de prueba y diferencia observada.

15.24 Flujo práctico de validación

Un flujo responsable para validar inyecciones puede ser:

1. Identificar entradas controlables.
2. Determinar el contexto probable: SQL, NoSQL, shell, LDAP, plantilla o XML.
3. Probar cambios inocuos y observar diferencias.
4. Comparar respuesta normal y respuesta alterada.
5. Usar datos de laboratorio siempre que sea posible.
6. Evitar extracción, modificación o comandos peligrosos.
7. Recolectar evidencia mínima.
8. Asignar severidad según impacto real.
9. Recomendar prevención específica para el contexto.

15.25 Qué debes recordar de este tema

• Las inyecciones ocurren cuando datos no confiables se interpretan como instrucciones.
• SQLi, NoSQLi y command injection comparten el problema de mezclar datos y lógica.
• La validación debe demostrar impacto sin extraer ni modificar datos innecesariamente.
• Las inyecciones ciegas requieren paciencia y límites para no afectar disponibilidad.
• La prevención se basa en parametrización, validación de esquema, APIs seguras y mínimo privilegio.
• La evidencia debe comparar comportamiento normal y manipulado con claridad.

15.26 Conclusión

Las inyecciones siguen siendo una familia crítica de vulnerabilidades porque conectan entradas externas con sistemas de alto valor. Validarlas exige precisión, control y respeto por los datos.

En el próximo tema estudiaremos XSS, CSRF, SSRF, deserialización insegura y fallas de control de acceso, ampliando el análisis hacia vulnerabilidades de navegador, sesiones, llamadas internas y autorización.