Cómo evolucionan las directrices de programación segura

La semana pasada estuve investigando vulnerabilidades en Java Spring para actualizar nuestras directrices de programación segura. Revisé los desafíos existentes en nuestra plataforma y noté algunos sobre XSS mediante la visualización de parámetros de URL en páginas JSP. Un ejemplo de código incorrecto se vería similar a lo siguiente:

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

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

Ahora, mi trabajo es formular la directriz de programación segura de una manera que sea clara para los desarrolladores y que los restrinja lo menos posible, manteniendo la seguridad del código. En este caso, preferiría permitir que los desarrolladores mantengan la funcionalidad deseada y recomendarles que lo hagan de forma segura escapando el parámetro de URL. De esta manera, el código ya no contiene una vulnerabilidad XSS. El ejemplo anterior puede asegurarse así:

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

Y esta fue nuestra directriz de programación segura durante unos días, hasta que me topé con una página de OWASP sobre inyección de lenguaje de expresiones. Esta página describe cómo se puede abusar del lenguaje de expresiones de Spring (SpEL) para realizar inyecciones con un impacto grave, incluida la ejecución remota de código. Dependía de mí determinar si podía haber casos en los que el código que cumple con nuestra directriz de programación segura aún pudiera verse afectado por esta vulnerabilidad. Así que escribí una aplicación de prueba rápida para evaluar expresiones SpEL y probé entradas con y sin escape XML para ver si podía encontrar escenarios que no fueran detectados. Y así fue, existen expresiones maliciosas que no contienen caracteres detectados por XmlEscape. Publiqué la demostración funcional en nuestro GitHub, la cual pueden encontrar aquí.

Y, por supuesto, actualicé nuestra directriz de programación segura, que ahora dice: "No muestre ni evalúe parámetros de URL utilizando el lenguaje de expresiones de Spring (SpEL)".

El impacto general de este problema es alto, por las siguientes razones: - Un atacante podría modificar e invocar funcionalidades en el servidor de aplicaciones. - Acceso no autorizado a datos y funcionalidades, 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