Cómo evolucionan las directrices de codificación segura

La semana pasada estuve investigando las vulnerabilidades en Java Spring para actualizar nuestras directrices de codificación segura. Estaba analizando los desafíos existentes en nuestra plataforma y me di cuenta de que había algunos en XSS al mostrar los parámetros de URL en las páginas JSP. El ejemplo de código incorrecto tendría un aspecto similar al siguiente:

<input type="text" name="username" value="${param.username}">

La solución correcta era eliminar el parámetro URL por completo y la descripción menciona que escapar del parámetro URL de la manera correcta también es seguro.

Ahora, mi trabajo consiste en formular la guía de codificación segura de una manera que sea clara para los desarrolladores y las restrinja lo menos posible mientras sigo escribiendo código seguro. En este caso, preferiría dejar que los desarrolladores conserven la funcionalidad deseada y recomendarles que lo hagan de forma segura evitando el parámetro URL. De esta forma, el código ya no contiene una vulnerabilidad de XSS. El ejemplo anterior se puede proteger de la siguiente manera:

<input type="text" name="username" value="${fn:escapeXml(param.username)}">

Y esta fue nuestra guía de codificación segura durante unos días, hasta que me topé con una Página de OWASP sobre la inyección de lenguaje de expresión. Esta página describe cómo se puede abusar del Spring Expression Language (SpEL) para inyectarlo con graves consecuencias, incluida la ejecución remota de código. Yo tenía que averiguar si había casos en los que el código que cumplía nuestra directriz de codificación segura pudiera seguir viéndose afectado por esta vulnerabilidad. Así que escribí una aplicación de prueba rápida para evaluar las expresiones de SpEl y probé las entradas con y sin Xml para ver si podía encontrar algunos escenarios que no se detectaran. Y lo hice, hay expresiones maliciosas que no contienen ningún carácter detectado por XMLescape. He publicado la demostración funcional en nuestro github, que puedes encontrar aquí.

Y, por supuesto, he actualizado nuestra guía de codificación segura, que ahora dice: «No muestre ni evalúe los parámetros de URL con el Spring Expression Language (SpEL)».

El impacto general de este problema es elevado, por las siguientes razones: - Un atacante podría modificar e invocar funciones en el servidor de aplicaciones. - Acceso no autorizado a datos y funciones, así como secuestro de cuentas y ejecución remota de código. - Problemas de confidencialidad e integridad derivados de un ataque exitoso.

https://www.owasp.org/index.php/Expression_Language_Injection