Cómo evolucionan las directrices de codificación segura

La semana pasada estuve investigando vulnerabilidades en Java Spring para poner al día nuestras directrices de codificación segura. Estaba revisando los retos existentes en nuestra plataforma y me di cuenta de unos cuantos sobre XSS a través de la visualización de parámetros url en páginas JSP. El ejemplo de código incorrecto sería algo similar a lo 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 el parámetro URL de la manera correcta también es seguro.

Ahora, mi trabajo es formular la pauta de codificación segura de una manera que sea clara para los desarrolladores y los restrinja lo menos posible sin dejar de escribir código seguro. En este caso, prefiero dejar que los desarrolladores mantengan su funcionalidad prevista y recomendarles que lo hagan de forma segura escapando del parámetro de la URL. De esta manera, el código ya no contiene una vulnerabilidad XSS. El ejemplo anterior se puede asegurar así:

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

Y esta fue nuestra pauta 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 el Lenguaje de Expresión de Spring (SpEL) puede ser abusado para la inyección con algún impacto serio, incluyendo la ejecución remota de código. Me tocó averiguar si podría haber casos en los que el código que se adhiere a nuestra directriz de codificación segura todavía puede ser afectado por esta vulnerabilidad. Así que escribí una aplicación de prueba rápida para evaluar las expresiones SpEL, y probé la entrada con y sin escape Xml para ver si podía encontrar algunos escenarios que no fueran capturados. Y lo hice, hay expresiones maliciosas que no contienen ningún carácter capturado por XmlEscape. He publicado la demo en nuestro github, que puedes encontrar aquí.

Y, por supuesto, he actualizado nuestra directriz de codificación segura que ahora dice: "No muestre o evalúe los parámetros de la URL utilizando el Lenguaje de Expresión de Spring (SpEL)".

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

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