Por José Eduardo Torres
Dando continuidad al tema del Top 10 2021 de OWASP (Open Web Application Security Project) sobre los riesgos más frecuentes en las aplicaciones, hablando ahora sobre el riesgo que se presenta en la tercera posición de este top el cual va relacionado a los problemas de inyección de código en nuestra aplicación.
Como podemos ver, este riesgo se presentó en la posición número 1 en el pasado top 10 del 2017, en los últimos 4 años se ha presentado un gran por los desarrolladores ha sido enorme para mitigar este riesgo, sin embargo, aun que hoy en día no es el riesgo más frecuente, se sigue presentando en una posición muy alta, por lo que sigue siendo un problema que se presenta regularmente en distintas aplicaciones, por lo que no podemos bajar la guardia ante esta vulnerabilidad. Un cambio que también podemos observar es que el riesgo que se presentó en la posición 7 del 2017 Cross-Site Scripting (‘XSS’) se juntó con esta vulnerabilidad, esto debido a que la naturaleza de este ataque, la cual explicaremos más adelante, es la misma a otros ataques de inyección, donde unos se explotan del lado del servidor y otros, cómo XSS, se ejecutan del lado del cliente.
Los ataques de inyección ocurren cuando se inserta código, como SQL, NoSQL, OS, XML, XSS o LDAP, como parte de una consulta, este código puede engañar al intérprete para que ejecute comandos involuntarios o acceda a los datos sin la debida autorización. Conociendo esto, veamos bajo que escenarios nuestra aplicación puede ser vulnerable
- Los datos suministrados por el usuario no son validados, filtrados o sanitizados 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.
Conociendo esto, entendamos como se explota este riesgo con un ejemplo de inyección SQL, una aplicación puede ser vulnerable si ingresamos un valor y la aplicación realiza una consulta de información en base a este.
Para saber si la aplicación es vulnerable, pudiéramos ingresar una comilla simple, si la aplicación es vulnerable, esta comilla simple provocara un erro de sintaxis en el query SQL, por lo que la aplicación nos mostrara un mensaje de error default.
Una vez que nos ha dado un mensaje default del servidor, podemos decir que la aplicación es vulnerable, por lo que comenzamos a agregar código en la consulta original para engañar al interprete y así poder extraer información de la base de datos.
Es aquí donde este riesgo recibe su nombre de inyección, por que se “inyecta” código para engañar al interprete y obtener información de la base de datos, conociendo como se explota la vulnerabilidad hay que entender por que sucede esto, y la respuesta es, como ya mencionamos al principio, que la aplicación no filtra la entrada de datos, por lo que la información que se ingresa se concatena directamente en el query sin haber pasado por un proceso de filtrado o sanitización.
Veamos otro escenario de ataque con un ejemplo de Cross-Site Scripting (XSS), nosotros podemos darnos cuenta de que la aplicación es vulnerable cuando el texto que nosotros ingresamos en la aplicación es plasmado tal cual nosotros lo escribimos en el código HTML.
Cómo el texto que ingresamos se representa tal cual en el código HTML, aquí es donde comenzamos a ingresar código Java Script para jugar con lo que se ejecuta del lado del cliente y poder robar sesiones posteriormente.
El impacto de los ataques de inyección puede ir desde el robo de información y sesiones, hasta la ejecución de comandos en el servidor, por lo que es importante saber si nuestra aplicación es vulnerable, sin embargo, es necesario conocer también como estar preparado para defenderse ante este tipo de ataques, por lo que aquí dejamos algunas medidas preventivas:
- 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.
- Realice validaciones de entradas de datos en el servidor, utilizando “listas blancas”.
- Para cualquier consulta dinámica residual, escape caracteres especiales utilizando la sintaxis de caracteres específica para el intérprete que se trate.
- Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la fuga masiva de registros en caso de inyección SQL
- De ser posible, utilice formatos de datos menos complejos como JSON y evite la serialización de datos confidenciales.
- Actualice los procesadores y bibliotecas XML que utilice la aplicación o el sistema subyacente. Utilice validadores de dependencias. Actualice SOAP a la versión 1.2 o superior.
- Utilizar frameworks seguros que, por diseño, automáticamente codifican el contenido para prevenir XSS, como en Ruby 3.0 o React JS.
- Codificar los datos de requerimientos HTTP no confiables en los campos de salida HTML.
En conclusión, este es un riesgo que tiene un gran impacto a nuestra aplicación debido a que permite la ejecución de comandos del lado de nuestro servidor, por lo que es importante conocer si somos vulnerables y que podemos hacer para remediarlo, si bien, hoy en día la frecuencia de este tipo de ataques ha bajado, sigue siendo un riesgo muy frecuente debido a que hay aplicaciones que requieren reducir sus tiempos de ejecución lo mas posible, por lo que evitan los procesos de filtrado, es aquí donde se entra a un debate sobre como protegernos sin sacrificar los tiempos de ejecución. Al igual que las medidas de seguridad, los ataques también evolucionan, por lo que hay que reducir las probabilidades de ser atacados para no quedar expuestos a nuevas amenazas.
