Tema 5
Las fallas de inyección aparecen cuando una aplicación mezcla datos controlados por el usuario con instrucciones que luego interpreta una base de datos, un shell, un directorio o cualquier otro motor. Es una de las familias de vulnerabilidades más peligrosas porque convierte entrada no confiable en comportamiento no previsto.
En una aplicación web es muy común que datos recibidos desde el usuario terminen participando en consultas, filtros, búsquedas, comandos del sistema, rutas de archivos o llamadas a otros servicios. Eso no es un problema por sí mismo. El problema aparece cuando esos datos se insertan de forma insegura dentro de una instrucción que otro componente interpreta.
En ese momento la aplicación deja de tratar la entrada como dato y empieza a tratarla, total o parcialmente, como instrucción. Allí nace la inyección.
Las fallas de inyección son especialmente relevantes porque pueden afectar confidencialidad, integridad y disponibilidad, y en algunos casos permitir ejecución remota de acciones críticas.
La lógica general es simple:
El caso más conocido es SQL Injection, pero el mismo patrón puede aparecer en otros contextos: comandos del sistema operativo, consultas NoSQL, expresiones LDAP, plantillas, rutas o llamadas a intérpretes.
Una aplicación queda expuesta cuando usa entrada no confiable para formar instrucciones dinámicas sin separar claramente datos y código. Esto suele ocurrir por:
SQL Injection ocurre cuando datos controlados por el usuario alteran una consulta SQL. Es una de las vulnerabilidades más conocidas y más estudiadas, pero sigue apareciendo porque muchas aplicaciones todavía construyen consultas de forma insegura.
Por ejemplo, si una búsqueda, un login o un filtro incorporan directamente texto enviado por el usuario dentro de una sentencia SQL, un atacante puede modificar la lógica esperada de la consulta.
El impacto depende de los privilegios de la cuenta usada por la aplicación y del diseño del backend, pero puede incluir lectura de datos, alteración de registros, bypass de autenticación o incluso daño mayor si la explotación progresa.
No todos los sistemas son explotables al mismo nivel, pero incluso una lectura parcial de datos ya puede representar un incidente grave.
| Escenario | Entrada vulnerable | Consecuencia posible |
|---|---|---|
| Formulario de login | Usuario y contraseña usados en consulta dinámica | Bypass de autenticación |
| Búsqueda interna | Término interpolado en cláusulas SQL | Lectura no autorizada o errores reveladores |
| Filtros administrativos | Ordenamiento, IDs o estados manipulables | Exposición o alteración de datos |
| Reportes | Fechas o rangos incorporados sin parametrizar | Consulta alterada o ampliada indebidamente |
Las bases NoSQL no eliminan automáticamente el problema de inyección. Si la aplicación construye filtros o expresiones a partir de entrada externa sin control adecuado, también puede exponerse a manipulación.
En sistemas que usan documentos JSON, objetos o operadores especiales, el riesgo aparece cuando el backend acepta estructuras inesperadas, tipos no previstos o condiciones que modifican el comportamiento del filtro original.
Un error común es asumir que porque no existe SQL textual entonces no puede haber inyección. Esa conclusión es falsa. El problema sigue siendo mezclar datos no confiables con lógica interpretable por el motor.
La inyección de comandos ocurre cuando una aplicación usa entrada del usuario para construir y ejecutar comandos del sistema operativo. Este escenario es extremadamente delicado porque puede permitir que el atacante ejecute acciones directamente en el entorno del servidor.
Esto suele aparecer cuando el backend invoca herramientas del sistema para procesar archivos, consultar servicios, comprimir contenido, convertir formatos o ejecutar scripts auxiliares.
Si el dato externo se concatena dentro del comando sin separación segura, el atacante puede cambiar la orden prevista o encadenar acciones adicionales.
Cuando una inyección de comandos es explotable, sus consecuencias suelen ser especialmente severas:
El impacto real depende del usuario del sistema con que corre la aplicación y del entorno donde se despliega, pero puede escalar rápidamente.
El mismo patrón de inyección puede aplicarse a otros intérpretes o motores. Por ejemplo:
Aunque cambie la tecnología, la pregunta defensiva sigue siendo la misma: ¿estamos separando correctamente los datos de la sintaxis interpretable?
Una defensa incompleta muy frecuente consiste en intentar bloquear algunos caracteres considerados peligrosos, por ejemplo comillas, punto y coma o símbolos concretos. El problema es que este enfoque suele ser frágil por varias razones:
La defensa real no es "limpiar cadenas hasta que parezcan seguras", sino evitar construir instrucciones de forma insegura.
La defensa más importante contra SQL Injection es usar consultas parametrizadas o prepared statements. Este enfoque separa claramente la estructura de la consulta de los datos proporcionados por el usuario.
Con este mecanismo, el motor recibe por un lado la consulta con placeholders y por otro los valores. Así, los datos se tratan como datos y no como parte de la sintaxis SQL.
Este principio general también se traduce a otras tecnologías: usar APIs estructuradas, builders seguros y mecanismos que separen parámetros de instrucciones.
Muchos frameworks y ORMs reducen el riesgo de SQL Injection cuando se usan correctamente, pero no lo eliminan por arte de magia. Si el desarrollador incorpora consultas dinámicas inseguras, usa fragmentos crudos o concatena partes de la instrucción manualmente, la vulnerabilidad puede reaparecer.
La herramienta ayuda, pero la responsabilidad sigue siendo del diseño y del uso correcto de sus APIs.
Aunque la defensa principal frente a inyección es separar datos e instrucciones, la validación sigue siendo importante. Restringir tipo, longitud, formato y conjunto de valores aceptables reduce exposición y ayuda a detectar comportamientos anómalos antes de que lleguen a capas más sensibles.
Por ejemplo, si un parámetro debe ser un entero positivo o una opción de un conjunto cerrado, el sistema no debería aceptar texto libre arbitrario. Esta validación no reemplaza la parametrización, pero sí agrega una capa útil de control.
Incluso si una aplicación sufre una inyección, el impacto puede reducirse si la cuenta de base de datos utilizada tiene privilegios mínimos. Un error frecuente es conectar la aplicación con usuarios demasiado poderosos, capaces de modificar tablas, crear estructuras o acceder a datos innecesarios.
El mínimo privilegio ayuda a limitar daño en caso de explotación:
En command injection, una defensa práctica muy importante es evitar invocar el shell del sistema si existe una API nativa o una biblioteca segura que resuelva la misma tarea. Procesar archivos, mover rutas, obtener metadatos o hacer conversiones suele poder hacerse sin construir comandos textuales.
Si no es necesario llamar al sistema operativo, se elimina una gran parte del riesgo.
Hay ciertos patrones que deberían encender una alarma temprana durante una revisión de código o diseño:
| Tipo de inyección | Motor afectado | Impacto típico |
|---|---|---|
| SQL Injection | Base de datos relacional | Lectura, alteración o borrado de datos; bypass de autenticación |
| NoSQL Injection | Base documental o clave-valor | Filtros manipulados, lectura indebida, evasión de controles |
| Command Injection | Sistema operativo | Ejecución de comandos, acceso al servidor, daño amplio |
| LDAP Injection | Directorio | Bypass, enumeración o acceso indebido a información del directorio |
Las fallas de inyección están estrechamente relacionadas con varios ejes de seguridad web:
Por eso una aplicación robusta no depende de una sola capa, sino de varias medidas que se refuerzan entre sí.
Las fallas de inyección siguen siendo una de las categorías más peligrosas porque convierten un error de procesamiento de datos en control sobre consultas, comandos o expresiones críticas. Entender su lógica permite identificar patrones inseguros antes de que lleguen a producción y diseñar capas de defensa realmente efectivas.
En el próximo tema estudiaremos otra familia de vulnerabilidades muy frecuente y ligada al navegador: Cross-Site Scripting, o XSS.