OWASP Top Ten 2017 (es)

A1:2017-Inyección

Languages: en de [es]
Agente de amenaza / Vector de ataque Debilidades de seguridad Impacto
Específico
de la Apl.
Explotabilidad: 3 Prevalencia: 2 Detectabilidad: 3 Técnico: 3 ¿Negocio?
Casi 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. Los defectos de inyección ocurren cuando un atacante puede enviar información dañina a un intérprete.
Estos defectos son muy comunes, particularmente en código heredado. Las vulnerabilidades de inyección se encuentran a menudo en consultas SQL, NoSQL, LDAP, XPath, comandos del SO, analizadores XML, encabezados SMTP, lenguajes de expresión, parámetros y consultas ORM. Los errores de inyección son fáciles de descubrir al examinar el código y los escáneres y fuzzers ayudan a encontrarlos.
Una inyección puede causar divulgación, pérdida o corrupción de información, pérdida de auditabilidad, o denegación de acceso.
El impacto al negocio depende de las necesidades de la aplicación y de los datos.
¿La aplicación es vulnerable?
Una aplicación es vulnerable a ataques de este tipo cuando:
* Los datos suministrados por el usuario no son validados, filtrados o saneados por la aplicación.
* Se invocan consultas dinámicas o no parametrizadas, sin codificar los parámetros de forma acorde al contexto.
* Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas Object-Relational Mapping (ORM), para extraer registros adicionales sensibles.
* Los datos dañinos se usan directamente o se concatenan, de modo que el SQL o comando resultante contiene datos y estructuras con consultas dinámicas, comandos o procedimientos almacenados.
Algunas de las inyecciones más comunes son SQL, NoSQL, comandos de SO, Object-Relational Mapping (ORM), LDAP, y Lenguaje de Expresiones o inyección Object Graph Navigation Library (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, seguido de cerca por pruebas automatizadas de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y entradas de datos XML. Las organizaciones pueden incluir herramientas de análisis estático (SAST) y pruebas dinámicas (DAST) para identificar errores de inyección apenas se introducen y antes del despliegue de la aplicación en producción.
Cómo se previene
Para prevenir inyecciones, se requiere separar los datos de los comandos y las consultas.
* La opción preferida es utilizar una API segura, que evite el uso de un intérprete por completo y proporcione una interfaz parametrizada. Se debe migrar y utilizar una herramientas de Mapeo Relacional de Objetos (ORMs).
Nota: Incluso cuando se parametrizan, los procedimientos almacenados pueden introducir una inyección SQL si el procedimiento PL/SQL o T-SQL concatena consultas y datos, o se ejecutan parámetros utilizando EXECUTE IMMEDIATE o exec().
* Realice validaciones de entradas de datos en el servidor, utilizando “listas blancas”. De todos modos, esto no es una defensa completa ya que muchas aplicaciones requieren el uso de caracteres especiales, como en campos de texto, APIs o aplicaciones móviles.
* Para cualquier consulta dinámica residual, escape caracteres especiales utilizando la sintaxis de caracteres específica para el intérprete que se trate.
Nota: Las estructuras de SQL tales como nombres de tabla, nombres de columna, etc. no se pueden escapar y, por lo tanto, los nombres de estructura suministrados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes.
* Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la fuga masiva de registros en caso de inyección SQL.
Ejemplos de escenarios de ataque
Escenario #1: la aplicación utiliza datos no confiables en la construcción del siguiente comando SQL vulnerable:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Escenario #2: la confianza total de una aplicación en su marco de trabajo puede resultar en consultas que aún son vulnerables a inyección, por ejemplo, Hibernate Query Language (HQL):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
En ambos casos, al atacante puede modificar el parámetro “id” en su navegador para enviar: ‘ or ‘1’=’1. Por ejemplo:
http://example.com/app/accountView?id=' or '1'='1

Esto cambia el significado de ambas consultas, devolviendo todos los registros de la tabla “accounts”. Ataques más peligrosos podrían modificar los datos o incluso invocar procedimientos almacenados.
Referencias