Descripción
- Agentes de amenazas o vectores de ataque: Cualquier fuente de datos puede ser un vector de inyección, variables de entorno, parámetros, servicios web externos e internos y todo tipo de usuarios. Las fallas de inyección ocurren cuando un atacante puede enviar datos hostiles a un intérprete.
- Debilidad de seguridad: Los defectos de inyección son muy frecuentes, especialmente en el código heredado. Las vulnerabilidades de inyección a menudo se encuentran en consultas SQL, LDAP, XPath o NoSQL, comandos del sistema operativo, analizadores XML, encabezados SMTP, lenguajes de expresión y consultas ORM. Los defectos de inyección son fáciles de descubrir al examinar el código. Los escáneres y los pueden ayudar a los atacantes a encontrar defectos de inyección.
- Impactos: La inyección puede ocasionar pérdida de datos, corrupción o divulgación a partes no autorizadas, pérdida de responsabilidad o denegación de acceso. La inyección a veces puede conducir a la adquisición completa del host. El impacto empresarial depende de las necesidades de la aplicación y los datos.
¿Es la aplicación vulnerable ?
Una aplicación es vulnerable a ataques cuando:
- La aplicación no valida, filtra ni desinfecta los datos proporcionados por el usuario.
- Las consultas dinámicas o las llamadas no parametrizadas sin escape contextual se utilizan directamente en el intérprete.
- Los datos hostiles se utilizan dentro de los parámetros de búsqueda del mapeo relacional de objetos (ORM) para extraer registros confidenciales adicionales.
- Los datos hostiles se usan o concatenan directamente, de modo que el SQL o el comando contienen tanto estructura como datos hostiles en consultas dinámicas, comandos o procedimientos almacenados.
- Algunas de las inyecciones más comunes son SQL, NoSQL, comando del sistema operativo, mapeo relacional de objetos (ORM), LDAP y lenguaje de expresión (EL) o inyección de biblioteca de navegación de gráfico de objetos (OGNL). El concepto es idéntico entre todos los intérpretes. La revisión del código fuente es el mejor método para detectar si las aplicaciones son vulnerables a las inyecciones, seguido de cerca por pruebas automatizadas exhaustivas de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y entradas de datos XML. Las organizaciones pueden incluir herramientas de fuente estática (SAST) y de prueba de aplicación dinámica (DAST) en la tubería de CI / CD para identificar fallas de inyección recién introducidas antes del despliegue de producción.
Cómo prevenir
La prevención de la inyección requiere mantener los datos separados de los comandos y consultas.
- La opción preferida es usar una API segura, que evita el uso del intérprete por completo o proporciona una interfaz parametrizada, o migra para usar herramientas de mapeo relacional de objetos (ORM). Nota: Incluso cuando se parametrizan, los procedimientos almacenados aún pueden introducir la inyección de SQL si PL / SQL o T-SQL concatena consultas y datos, o ejecuta datos hostiles con EXECUTE INMEDIATE o exec ().
- Utilice la validación de entrada positiva o "lista blanca" del lado del servidor. Esto no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales, como áreas de texto o API para aplicaciones móviles.
- Para cualquier consulta dinámica residual, escape caracteres especiales usando la sintaxis de escape específica para ese intérprete. Nota: la estructura SQL, como los nombres de tabla, los nombres de columna, etc., no se pueden escapar, por lo que los nombres de estructura proporcionados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes.
- Use LIMIT y otros controles SQL dentro de las consultas para evitar la divulgación masiva de registros en caso de inyección SQL.
Ejemplos de escenarios de ataque
Escenario n. ° 1: Una aplicación utiliza datos no confiables en la construcción de la siguiente llamada SQL vulnerable:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Escenario n. ° 2: De manera similar, la confianza ciega de una aplicación en los marcos puede generar consultas que aún son vulnerables (por ejemplo, Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
En ambos casos, el atacante modifica el valor del parámetro 'id' en su navegador para enviar: 'o' 1 '=' 1. Por ejemplo:
http://example.com/app/accountView?id=' or '1'='1
Esto cambia el significado de ambas consultas para devolver todos los registros de la tabla de cuentas. Los ataques más peligrosos podrían modificar o eliminar datos, o incluso invocar procedimientos almacenados.
Referencias:
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection
- OWASP Proactive Controls: Parameterize Queries
- OWASP ASVS: V5 Input Validation and Encoding
- OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection
- OWASP Cheat Sheet: Injection Prevention
- OWASP Cheat Sheet: SQL Injection Prevention
- OWASP Cheat Sheet: Injection Prevention in Java
- OWASP Cheat Sheet: Query Parameterization
- OWASP Automated Threats to Web Applications – OAT-014