A03: La inyección (by OWASP) | Libros Tecnológicos

Visión general

La inyección se desliza hasta la tercera posición. El 94 % de las aplicaciones se probaron para alguna forma de inyección con una tasa de incidencia máxima del 19 %, una tasa de incidencia promedio del 3 % y 274 000 ocurrencias. Las Enumeraciones de debilidades comunes (CWE) notables incluidas son CWE-79: Cross-site Scripting , CWE-89: SQL Injection y CWE-73: External Control of File Name or Path .

Descripción

Una aplicación es vulnerable a un ataque 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 consciente del contexto se utilizan directamente en el intérprete.
Los datos hostiles se utilizan dentro de los parámetros de búsqueda de mapeo relacional de objetos (ORM) para extraer registros confidenciales adicionales.
Los datos hostiles se utilizan o concatenan directamente. El comando SQL o contiene la estructura y los datos maliciosos en consultas dinámicas, comandos o procedimientos almacenados.

Algunas de las inyecciones más comunes son SQL, NoSQL, comando OS, asignación relacional de objetos (ORM), LDAP e inyección de lenguaje de expresión (EL) o biblioteca de navegación de gráficos 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. Se recomienda encarecidamente la prueba automatizada de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y entradas de datos XML. Las organizaciones pueden incluir herramientas de prueba de seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en la canalización de CI/CD para identificar fallas de inyección introducidas antes de la implementación de producción.

Como prevenir

Prevenir la inyección requiere mantener los datos separados de los comandos y consultas:

La opción preferida es usar una API segura, que evita usar el intérprete por completo, proporciona una interfaz parametrizada o migra a herramientas de mapeo relacional de objetos (ORM). Nota: Incluso cuando están parametrizados, los procedimientos almacenados aún pueden introducir inyección SQL si PL/SQL o T-SQL concatenan consultas y datos o ejecutan datos hostiles con EXECUTE IMMEDIATE o exec().
Utilice una validación de entrada positiva del lado del servidor. Esta 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 los caracteres especiales usando la sintaxis de escape específica para ese intérprete. Nota: las estructuras SQL, como los nombres de las tablas, los nombres de las columnas, etc., no se pueden escapar y, por lo tanto, los nombres de estructuras proporcionados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes.
Utilice LIMIT y otros controles de SQL dentro de las consultas para evitar la divulgación masiva de registros en caso de inyección de SQL.

Ejemplos de escenarios de ataque

Escenario n.º 1: una aplicación utiliza datos que no son de confianza en la construcción de la siguiente llamada SQL vulnerable:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Escenario #2: De manera similar, la confianza ciega de una aplicación en los marcos puede dar como resultado 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.