La inyección de código es una vulnerabilidad crítica que permite que un tercero ejecute código en el software del lado del servidor. La inyección de lenguaje de expresión es un tipo de ejecución remota de código que revela datos confidenciales del servidor. El código remoto ejecuta y muestra variables, contraseñas, funciones o código. En el peor de los casos, puede dar a un atacante un control remoto del servidor.
¿Qué es la inyección de lenguaje de expresión?
La inyección de lenguaje de expresión es una vulnerabilidad que afecta a las páginas JavaServer (JSP), las páginas Active Server (ASP) y otros lenguajes de expresión alojados en un servidor web. Estos idiomas son lenguajes interpretados, por lo que cualquier código enviado al servidor se compila durante el tiempo de ejecución de la aplicación, en lugar de los lenguajes compilados estándar con archivos ejecutables binarios. En un lenguaje interpretado, el código se compila en el servidor cuando un usuario solicita una página.
Cuando una aplicación de lenguaje de expresión (EL) es vulnerable a la inyección de lenguaje de expresión, un atacante envía código creado a la aplicación como entrada, ya sea en la cadena de consulta o en un objeto de formulario. El código se compila en tiempo de ejecución y luego puede mostrar variables, contraseñas y otra información confidencial. Las vulnerabilidades de EL son comunes en las versiones obsoletas de los lenguajes interpretados, por lo que las aplicaciones heredadas deben probarse antes de desplegarlas en producción. Después de un evento crítico, las organizaciones necesitan planes de recuperación de desastres para remediar la divulgación y los exploits de los datos.
Cómo funciona la inyección de lenguaje de expresión
Cualquier aplicación que ejecute un lenguaje interpretado debe borrar el código y los caracteres especiales de la entrada. Sin borrar la entrada, la aplicación aceptará el código y lo ejecutará en el servidor. La mayoría de las vulnerabilidades de inyección de EL implican JSP, por lo que usaremos el código JSP en el siguiente ejemplo. El siguiente fragmento es un ejemplo de una única línea de código vulnerable a la inyección EL:
<spring:message code="${param['message']}" text=""/>
En este ejemplo, el atributo de código toma un parámetro que contiene una cadena. Si un atacante introduce código en el parámetro, este se compilará y ejecutará en el servidor. Los usuarios no ven este código en su página web local, por lo que los atacantes utilizan scripts comunes para encontrar vulnerabilidades de inyección de EL.
Vulnerabilidades comunes que conducen a la inyección del lenguaje de expresión
Al igual que cualquier vulnerabilidad a la inyección, la vulnerabilidad a la inyección EL se debe a que no se valida la entrada en la aplicación del servidor. Usando el mismo ejemplo anterior, la cadena de mensaje puede ser una cadena de caracteres inocente, pero también puede ser código. En lugar de enviar una cadena inocente, supongamos que el usuario ha enviado lo siguiente:
${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}
La entrada anterior intenta ejecutar el comando del sistema “ls -l” en el servidor. Este comando enumera los archivos y directorios del directorio actual. Con una lista de archivos, un atacante puede intentar enviar otro comando para abrir y mostrar el contenido de un archivo en su ventana. Un archivo puede contener datos confidenciales, como contraseñas. A partir de ahí, el atacante podría acceder al servidor y realizar acciones maliciosas adicionales.
Detección de la inyección del lenguaje de expresión
Las pruebas de penetración —tanto de caja blanca como de caja negra— detectarán las vulnerabilidades de la inyección de EL. Las pruebas de caja blanca son un método en el que los profesionales de la seguridad revisan el código en busca de vulnerabilidades. Las empresas suministran el código a los revisores de seguridad y los revisores identifican todas las vulnerabilidades del código en un informe. Es un enfoque proactivo común de la protección de datos.
Las pruebas de penetración de la caja negra utilizan la misma forma de análisis y detección de vulnerabilidades que un atacante. Los profesionales de la seguridad atacan la aplicación sin conocer el código, para que se pueda probar cualquier validación o defensa. Las pruebas de caja gris son una combinación de pruebas de caja negra y caja blanca y a menudo son un método elegido para las aplicaciones web de prueba de penetración.
Evitar la inyección del lenguaje de expresión
La mejor manera de detectar los ataques de inyección EL es validar el código y eliminar la entrada con caracteres específicos. Por ejemplo, la entrada para un campo de nombre no debe tener caracteres “<” or “>”. Los desarrolladores deben usar bibliotecas creadas para detectar estos caracteres y eliminarlos o dejar caer la entrada y mostrar un error al usuario.
Otros personajes también pueden ser malintencionados. En una página JSP, los fragmentos de código empiezan por los caracteres “<%” characters and end with the “%>”. Estos caracteres juntos deben eliminarse de la entrada. Los atacantes realizarán numerosas combinaciones de código malicioso para evitar la detección, por lo que la mejor manera de detectarlo es usar una biblioteca creada para la validación de las entradas. Las aplicaciones SIEM también pueden detectar exploits y proporcionar analíticas si su aplicación es un objetivo.
Conclusión
Las vulnerabilidades de la inyección EL deben tratarse como problemas críticos de seguridad. Haga que sus aplicaciones de lenguaje interpretado se sometan siempre a pruebas para detectar vulnerabilidades de inyección y cualquier otra que pueda revelar datos confidenciales. Los desarrolladores deben usar herramientas de validación para detectar y detener la inyección de EL y las aplicaciones heredadas que utilizan JSP y ASP deben supervisarse estrechamente para detectar ataques.
Pure Storage tiene implementada la infraestructura de seguridad y la supervisión de amenazas para proteger sus aplicaciones de los ataques de seguridad.
