Inyección SQL e inyección de comandos

SQL injection (SQLi) ocurre cuando un atacante inserta o «inyecta» código SQL malicioso en un campo de entrada que posteriormente se incluye en una consulta a una base de datos. Como la aplicación concatena directamente la entrada del usuario en una sentencia SQL, la base de datos no puede distinguir entre datos legítimos y comandos proporcionados por el atacante. SQLi ocupa sistemáticamente uno de los primeros puestos entre las vulnerabilidades web más peligrosas de OWASP Top 10.

Una consulta de inicio de sesión vulnerable podría tener este aspecto: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Si un atacante proporciona ' OR '1'='1 como nombre de usuario, la consulta se transforma de modo que la cláusula WHERE siempre sea verdadera, omitiendo por completo la autenticación. Esta es la clásica inyección basada en una tautología.

Los ataques de SQL injection adoptan varias formas: In-band SQLi devuelve los resultados directamente en la respuesta HTTP (basada en errores o en unions). Blind SQLi infiere los datos mediante respuestas booleanas de verdadero o falso o retrasos de tiempo deliberados (SLEEP(5)). Out-of-band SQLi utiliza canales secundarios, como consultas DNS, para extraer datos cuando las respuestas no son visibles.

La defensa principal contra SQL injection son las consultas parametrizadas (también llamadas prepared statements). En una consulta parametrizada, la estructura SQL se compila primero y la entrada del usuario se pasa como un parámetro independiente; nunca puede alterar la estructura de la consulta. Este enfoque es independiente del lenguaje y mucho más fiable que utilizar únicamente la desinfección de entradas.

Aunque las consultas parametrizadas son la defensa principal, la validación de entradas proporciona una importante capa secundaria. La validación mediante allowlist acepta únicamente los caracteres esperados (por ejemplo, solo caracteres alfanuméricos en un campo de nombre de usuario) y rechaza todo lo demás. La validación mediante denylist bloquea caracteres identificados como maliciosos, pero los atacantes suelen codificar u ofuscar los payloads para eludir las denylist, por lo que las allowlist son mucho más sólidas.

Command injection (inyección de comandos del sistema operativo) ocurre cuando una aplicación pasa entradas de usuario sin desinfectar a un shell del sistema. A diferencia de SQL injection, que ataca bases de datos, command injection ataca directamente el sistema operativo, lo que permite a los atacantes ejecutar comandos arbitrarios con los privilegios del proceso del servidor web. Tiene una gravedad crítica y con frecuencia provoca el compromiso total del sistema.

Una aplicación web que hace ping a una dirección IP proporcionada por el usuario podría utilizar: ping -c 1 INPUT. Si un atacante proporciona 8.8.8.8; cat /etc/passwd, el shell interpreta ; como separador de comandos y ejecuta ambos comandos. Entre los operadores de inyección habituales se incluyen ;, &&, ||, | y la sustitución de comandos mediante backticks.

La defensa más segura contra command injection consiste en evitar por completo llamar a comandos del sistema operativo a partir de entradas del usuario y utilizar funciones de biblioteca que logren el mismo objetivo. Cuando no sea posible evitar las llamadas al shell, pase los argumentos como una lista (nunca como una cadena concatenada), desactive la interpretación del shell, valide la entrada mediante una allowlist estricta y ejecute los procesos con la cuenta de usuario con los mínimos privilegios posibles.

El Top 10 de OWASP incluye la inyección (que abarca la inyección SQL, NoSQL, del sistema operativo y LDAP) como uno de los riesgos más críticos para la seguridad de las aplicaciones. OWASP recomienda un enfoque de defensa en profundidad: utilizar API seguras que eviten el intérprete, realizar una validación positiva de las entradas en el servidor (lista de permitidos), escapar los caracteres especiales mediante la sintaxis específica de ese intérprete y utilizar controles SQL como LIMIT para evitar la divulgación masiva de datos.

Un firewall de aplicaciones web (WAF) puede detectar y bloquear cargas útiles de inyección habituales inspeccionando las solicitudes HTTP y comparándolas con patrones de firmas. Sin embargo, los WAF pueden evadirse mediante técnicas de codificación y no sustituyen la programación segura. Un registro adecuado de la aplicación —que incluya los parámetros de consulta, los códigos de respuesta y los mensajes de error— permite a los equipos de seguridad identificar intentos de inyección durante el análisis de incidentes.

Los ataques de inyección han causado algunas de las mayores filtraciones de datos de la historia. La filtración de Equifax de 2017 expuso 147 millones de registros mediante una vulnerabilidad de una aplicación web. Un ataque de inyección SQL contra PlayStation Network de Sony comprometió 77 millones de cuentas en 2011. Estos incidentes ilustran que las vulnerabilidades de inyección tienen un impacto empresarial extremo: el robo de datos, las multas regulatorias, el daño a la reputación y la responsabilidad legal son consecuencias de un ataque de inyección exitoso.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: la inyección SQL explota entradas no saneadas concatenadas en consultas de base de datos, la inyección de comandos envía entradas maliciosas al shell del sistema operativo mediante operadores como ; y | y las consultas parametrizadas y evitar shell=True son las principales defensas. A continuación, estudiaremos los ataques de Cross-Site Scripting (XSS) y CSRF.