Tema 11
Una API no existe aislada: consulta bases de datos, llama a servicios internos, procesa plantillas, manipula archivos y deserializa datos. Cuando las entradas controladas por el cliente alcanzan esas capas sin las defensas adecuadas, aparecen las inyecciones. Su peligro no está solo en el dato malicioso, sino en que la API lo interpreta como instrucciones en lugar de tratarlo como simple información.
Las inyecciones siguen siendo una familia crítica de vulnerabilidades porque aprovechan una situación muy común: la aplicación construye una instrucción para otra capa usando datos que provienen, directa o indirectamente, del cliente. Si esos datos no se separan bien de la lógica o del comando, el atacante puede modificar el significado de la operación.
En APIs REST, estas fallas pueden aparecer en búsquedas, filtros, generación de reportes, consultas dinámicas, llamadas al sistema operativo, rendering de plantillas, deserialización de objetos o procesamiento de documentos. El hecho de que la API reciba JSON en lugar de formularios tradicionales no elimina este riesgo. Solo cambia la forma en que el input llega al backend.
Este tema estudia las variantes más relevantes para APIs modernas: inyección SQL, NoSQL, comandos, plantillas y serialización insegura.
Una inyección ocurre cuando datos controlados por el atacante son interpretados como parte de una instrucción, consulta o estructura ejecutable en una capa posterior del sistema. El problema central no es el texto raro o el carácter especial en sí, sino la pérdida de separación entre datos y lógica.
En términos generales, hay una inyección cuando:
Existe el mito de que las APIs modernas, al usar frameworks, ORMs y JSON, ya no sufren inyecciones. En realidad, las inyecciones persisten porque:
La inyección SQL ocurre cuando datos controlados por el cliente alteran la consulta que la aplicación envía a una base relacional. Aunque hoy existen ORMs y consultas preparadas, el riesgo sigue presente cuando el código arma condiciones dinámicas, ordenamientos o fragmentos SQL a partir de entradas no controladas.
Escenarios frecuentes en APIs:
Una SQL Injection puede permitir mucho más que leer datos. Según privilegios y contexto, también puede modificar, borrar, insertar o incluso pivotear hacia otras capacidades del entorno.
| Capacidad obtenida | Consecuencia posible |
|---|---|
| Lectura arbitraria | Exfiltración masiva de datos sensibles |
| Modificación de registros | Fraude, corrupción de estados o pérdida de integridad |
| Borrado de datos | Daño operativo o sabotaje |
| Bypass de filtros lógicos | Acceso indebido a recursos o resultados |
La defensa principal es separar completamente datos e instrucciones mediante consultas parametrizadas o mecanismos equivalentes del framework o driver. Pero eso no siempre alcanza si se interpolan partes estructurales como nombres de columnas, operadores o fragmentos enteros.
Buenas prácticas clave:
Las bases NoSQL y motores documentales no están exentos de inyección. El problema aparece cuando el backend construye consultas dinámicas con objetos o estructuras que incluyen operadores controlados por el cliente.
Ejemplos típicos:
Una entrada maliciosa puede cambiar el significado de la consulta, ampliar el conjunto de resultados o saltear restricciones lógicas previstas por la API.
La inyección NoSQL suele pasar desapercibida porque el código parece “tipado” o estructurado, y no usa cadenas SQL clásicas. Pero el riesgo sigue siendo el mismo: la API permite que el cliente influya en la estructura de la consulta, no solo en sus valores.
Se vuelve especialmente peligrosa cuando:
La command injection ocurre cuando la API construye y ejecuta comandos del sistema operativo usando entradas controladas por el cliente. Esto puede suceder en tareas como conversión de archivos, procesamiento multimedia, compresión, ping, diagnósticos, backups o scripts operativos.
Riesgos típicos:
La mejor defensa suele ser evitar el shell por completo. Cuando sea posible, conviene usar librerías nativas o invocaciones con argumentos estructurados sin interpretación por shell.
Recomendaciones:
La inyección en plantillas aparece cuando datos controlados por el usuario son interpretados por un motor de templates como expresiones, variables o instrucciones ejecutables. Aunque suele asociarse a interfaces HTML, también puede aparecer en generación de correos, documentos, reportes o mensajes dinámicos expuestos por APIs.
El riesgo es mayor cuando la aplicación permite personalización avanzada, renderizado dinámico o almacenamiento de contenido que luego pasa por una plantilla sin aislamiento adecuado.
La serialización convierte objetos o estructuras en formatos transportables; la deserialización hace el camino inverso. El problema aparece cuando la API acepta datos serializados que luego reconstruyen estructuras internas complejas, activan comportamientos inesperados o permiten manipular tipos y propiedades críticas.
Riesgos frecuentes:
En APIs modernas este riesgo no siempre aparece como deserialización binaria clásica. A veces se manifiesta como mapeo automático excesivo desde JSON hacia modelos internos, eventos, expresiones o estructuras complejas que luego activan lógica no prevista.
Ejemplos prácticos:
No toda inyección se ejecuta en la primera capa del backend. A veces la API recibe una entrada, la almacena o la reenvía, y el efecto peligroso aparece más adelante cuando otro componente la interpreta. Esto puede suceder con colas, workers, motores de reportes, sistemas de búsqueda, ETL, plantillas o scripts de administración.
Ese carácter indirecto hace que la vulnerabilidad sea más difícil de detectar y a veces más dañina, porque cruza límites entre componentes que se suponen desacoplados.
Las APIs que ofrecen búsqueda avanzada son especialmente sensibles. Permitir filtros complejos, operadores dinámicos, expresiones regulares, ordenamientos libres o criterios anidados puede acercar mucho la entrada del cliente a la sintaxis interna del motor de datos.
Cuanto más expresiva es la interfaz de búsqueda, más importante es:
Aunque cada tipo de inyección tenga particularidades, hay principios defensivos que se repiten:
Hay ciertos olores de diseño que deberían encender alarmas tempranas:
Las inyecciones siguen siendo una amenaza crítica en APIs porque explotan una debilidad estructural: permitir que datos no confiables alteren el significado de consultas, comandos o estructuras internas. El problema no se resuelve solo con frameworks o con JSON; se resuelve diseñando la API y sus capas internas para que la entrada del cliente nunca se mezcle de forma peligrosa con la lógica ejecutable.
En el próximo tema estudiaremos la protección de datos sensibles en requests, responses y logs, para reducir la exposición de información crítica tanto en tránsito como en observabilidad y operación.