Las
fallas
de
inyección
ocurren
cuando
una
aplicación
envía
información
no
confiable
a
un
interprete.
Estas
fallas
son
muy
comunes,
particularmente
en
el
código
antiguo.
Se
encuentran,
frecuentemente,
en
las
consultas
SQL,
LDAP,
Xpath
o
NoSQL;
los
comandos
de
SO,
intérpretes
de
XML,
encabezados
de
SMTP,
argumentos
de
programas,
etc.
Estas
fallas
son
fáciles
de
descubrir
al
examinar
el
código,
pero
dificiles
de
descubrir
por
medio
de
pruebas.
Los
analizadores
y
«fuzzers»
pueden
ayudar
a
los
atacantes
a
encontrar
fallas
de
inyección.
Verificar el código es una manera rápida y precisa para ver si la aplicación usa intérpretes de manera segura. Herramientas de análisis de código pueden ayudar al analista de seguridad a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testadores pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad.
El análisis dinámico automatizado, el cual ejercita la aplicación puede proveer una idea de si existe alguna inyección explotable. Los analizadores automatizados no siempre pueden alcanzar a los intérpretes y se les dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las inyecciones fáciles de descubrir.
¿Puedo ser vulnerable?
La mejor manera de averiguar si una aplicación es vulnerable a una inyección es verificar que en todo uso de intérpretes se separa la información no confiable del comando o consulta. Para llamados SQL, esto significa usar variables parametrizadas en todas las sentencias preparadas (prepared statements) y procedimientos almacenados, evitando las consultas dinámicas.Verificar el código es una manera rápida y precisa para ver si la aplicación usa intérpretes de manera segura. Herramientas de análisis de código pueden ayudar al analista de seguridad a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testadores pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad.
El análisis dinámico automatizado, el cual ejercita la aplicación puede proveer una idea de si existe alguna inyección explotable. Los analizadores automatizados no siempre pueden alcanzar a los intérpretes y se les dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las inyecciones fáciles de descubrir.
Ejemplos de Ataques
Ejemplo #1: La aplicación usa datos no confiables en la construcción de la siguiente instrucción SQL vulnerable: Ejemplo #2: De manera similar, si una aplicación confia ciegamente en el framework puede resultar en consultas que aún son vulnerables, (ej., Hibernate Query Language (HQL)): En ambos casos, al atacante modificar el parámetro ‘id’ en su navegador para enviar: ' or '1'='1. Por ejemplo: Esto cambia el significado de ambas consultas regresando todos los registros de la tabla “accounts”. Ataques más peligrosos pueden modificar datos o incluso invocar procedimientos almacenados.¿Cómo prevenirlo?
Evitar una inyección requiere mantener los datos no confiables separados de los comandos y consultas.- La opción preferida es usar una API segura la cual evite el uso de interpretes por completo o provea una interface parametrizada. Sea cuidadoso con las APIs, como los procedimiento almacenados, que son parametrizados, pero que aún pueden introducir inyecciones en el motor del interprete.
- Si una API parametrizada no está disponible, debe codificar cuidadosamente los caracteres especiales, usando la sintaxis de escape específica del intérprete.
- La validación de entradas positiva o de "lista blanca" también se recomienda, pero no es una defensa integral dado que muchas aplicaciones requieren caracteres especiales en sus entradas. Si se requieren caracteres especiales, solo las soluciones anteriores 1. y 2. harían su uso seguro.
