SQL Injection: escala privilegios y corrígelo

El riesgo Injection ocupa la posición A03 del OWASP Top 10 y aparece cuando una aplicación web o móvil acepta datos del usuario sin sanitizarlos, validarlos ni filtrarlos. Si trabajas en desarrollo, pen testing o red team, entender este riesgo te ayuda a evitar accesos no autorizados, fugas de información y escaladas de privilegios.

La idea central es simple: cuando un input no controla lo que recibe, un atacante puede enviar una cadena mal formada, conocida como payload, y forzar a la aplicación a ejecutar instrucciones que jamás debió permitir. Desde una inyección SQL hasta comandos del sistema operativo, el patrón siempre se repite.

¿Cómo funciona una inyección SQL en una aplicación vulnerable?

Imagina una query donde el campo user_id se concatena directamente con la entrada del usuario. Si ese dato no se sanitiza, puedes inyectar instrucciones adicionales y manipular la base de datos a tu favor [01:30].

En la demostración práctica con la aplicación vulnerable, existen dos roles: administrador y usuario convencional con privilegios limitados. Desde la perspectiva del atacante, el formulario de perfil expone varios inputs: username, biografía, last name. El campo interesante es username, porque al revisar el código fuente en userindex.gs se descubre que la variable se concatena sin filtros [05:20].

¿Qué es un payload en ciberseguridad? Es una cadena mal formada que un atacante envía a un input vulnerable para alterar el comportamiento de la aplicación, como ejecutar instrucciones SQL o comandos del sistema.

El ataque toma como referencia el ID del usuario, que puede obtenerse con herramientas como SQLMap, y concatena una instrucción que actualiza el rol del usuario al rol 1, asignado al admin. Tras guardar los cambios, cerrar sesión y volver a entrar, aparece la opción de administrador con visibilidad de todos los usuarios. Privilegios escalados con éxito.

¿Qué impacto real tiene el riesgo injection en una empresa?

Un caso documentado muestra a una empresa cuyo portal web no sanitizaba la entrada de datos en un formulario que esperaba un hostname. Al insertar caracteres como ; ls -la, la aplicación ejecutaba la acción esperada y además listaba los archivos del directorio del servidor Linux, exponiendo ficheros como home e index.php [02:10].

El impacto va más allá de leer archivos. Con la combinación correcta de comandos, un atacante puede:

• Acceder a información sensible no autorizada.
• Modificar registros de la base de datos.
• Escalar privilegios dentro de la aplicación.
• Ejecutar comandos del sistema operativo del servidor.

Y aquí viene lo interesante: la inyección no se limita a SQL. También puedes inyectar JavaScript en aplicaciones web e incluso payloads específicos contra modelos de aprendizaje en inteligencia artificial.

¿Cómo prevenir el riesgo injection en tus aplicaciones?

La prevención combina prácticas de codificación segura con validaciones que dependen del lenguaje y framework que uses. La regla básica: nunca confíes en lo que llega del usuario.

Sanitización y queries parametrizadas como primera línea de defensa

Si tu aplicación espera un correo o un ID, valida que la entrada cumpla ese formato usando funciones reservadas del lenguaje. Después, evita la concatenación directa en sentencias SQL y usa queries parametrizadas, donde la variable (por ejemplo $1) ya viaja sanitizada hasta la base de datos [03:45].

En la corrección de la aplicación vulnerable se usa la librería DBQuery. El parámetro $1 recibe la cadena ya filtrada y se evita la inyección. Al volver a probar el payload anterior, la actualización falla. Control aplicado.

¿Qué hace LIMIT en una sentencia SQL desde la perspectiva de seguridad? Restringe el número de registros devueltos por la consulta, evitando que una query manipulada exponga más información de la necesaria.

Validación en el código fuente y revisión de inputs

Antes de desplegar, revisa el código fuente de cada formulario. Si encuentras que una variable se concatena sin pasar por una función de sanitización, ese campo es candidato directo a inyección. Algunas prácticas concretas:

1. Validar tipo de dato esperado en cada input.
2. Limitar el número de caracteres según la configuración de la aplicación.
3. Usar LIMIT en sentencias SQL para acotar la información devuelta.
4. Auditar el código fuente buscando concatenaciones sospechosas.

¿Qué diferencia hay entre concatenar y parametrizar una query? Concatenar une la entrada del usuario directamente con la sentencia SQL y permite inyecciones. Parametrizar envía el valor por separado, ya sanitizado, y la base de datos lo trata como dato, no como código.

¿Por qué injection sigue en el top 3 del OWASP Top 10?

Porque sigue siendo barato de explotar y caro de remediar. Basta con un campo mal validado para comprometer una base de datos completa o el sistema de archivos del servidor. Y, como mostró la demo, el salto de usuario convencional a administrador puede ocurrir con una sola cadena bien formada en el campo username.

Practica con tu propia aplicación vulnerable, prueba payloads, revisa el código y aplica los fixes. Cuéntame en los comentarios qué input fue el primero que lograste explotar y cómo lo corregiste.