A03:2021 – Inyección

injection

Resumen

La inyección desciende a la tercera posición. El 94% de las aplicaciones fueron evaluadas en busca de algún tipo de inyección, con una tasa de incidencia máxima del 19%, una tasa de incidencia promedio del 3% y 274,000 ocurrencias. Algunas de las enumeraciones de debilidades comunes (CWEs) notables incluidas son CWE-79: Cross-site Scripting, CWE-89: Inyección SQL, y CWE-73: Control Externo de Nombre de Archivo o Ruta.

Descripción

Una aplicación es vulnerable a ataques cuando:

  • Los datos proporcionados por el usuario no son validados, filtrados o sanitizados por la aplicación.
  • Se utilizan consultas dinámicas o llamadas no parametrizadas sin escape contextual directamente en el intérprete.
  • Datos hostiles se utilizan dentro de parámetros de búsqueda en un mapeo objeto-relacional (ORM) para extraer registros adicionales y sensibles.
  • Los datos hostiles se usan o concatenan directamente. El SQL o comando 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, comandos del sistema operativo, inyecciones de mapeo objeto-relacional (ORM), LDAP y inyecciones de Lenguaje de Expresiones (EL) o de la 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 inyecciones. Se recomienda encarecidamente realizar pruebas automatizadas de todos los parámetros, encabezados, URL, cookies, y entradas de datos JSON, SOAP y XML. Las organizaciones pueden incluir herramientas de pruebas de seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en el pipeline de CI/CD para identificar fallos de inyección antes del despliegue en producción.

Cómo prevenir una inyección de código malicioso

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

  • La opción preferida es utilizar una API segura, que evite el uso del intérprete por completo, proporcione una interfaz parametrizada o migre a herramientas de mapeo objeto-relacional (ORM). Nota: Incluso cuando se utilizan procedimientos almacenados parametrizados, pueden introducir inyección SQL si PL/SQL o T-SQL concatenan consultas y datos o ejecutan datos hostiles con EXECUTE IMMEDIATE o exec().
  • Utiliza validación de entradas positiva del lado del servidor. Esto no es una defensa completa, ya que muchas aplicaciones requieren caracteres especiales, como áreas de texto o APIs para aplicaciones móviles.
  • Para cualquier consulta dinámica residual, escapa los caracteres especiales utilizando la sintaxis de escape específica para ese intérprete. Nota: Las estructuras SQL como nombres de tablas, nombres de columnas, etc., no se pueden escapar, por lo que los nombres de estructuras proporcionados por el usuario son peligrosos. Este es un problema común en software de generación de informes.
  • Usa LIMIT y otros controles SQL dentro de las consultas para evitar la divulgación masiva de registros en caso de una inyección SQL.

Escenarios de Ataques Ejemplares

Escenario #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 #2: De manera similar, la confianza ciega de una aplicación en los frameworks puede resultar en consultas que aún son vulnerables, como en el caso del Lenguaje de Consultas de Hibernate (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: ' UNION SELECT SLEEP(10);--. Por ejemplo:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

Esto cambia el significado de ambas consultas para devolver todos los registros de la tabla de cuentas. Ataques más peligrosos podrían modificar o eliminar datos o incluso invocar procedimientos almacenados.

Referencias