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
La semana pasada estuve investigando vulnerabilidades en Java Spring para poner al día nuestras directrices de codificación segura.
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
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
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
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
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
Índice
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Asistentes de codificación de IA: Guía de navegación segura para la próxima generación de desarrolladores
Los grandes modelos lingüísticos ofrecen ventajas irresistibles en velocidad y productividad, pero también introducen riesgos innegables para la empresa. Las barandillas de seguridad tradicionales no bastan para controlar el diluvio. Los desarrolladores necesitan conocimientos de seguridad precisos y verificados para identificar y prevenir los fallos de seguridad desde el principio del ciclo de vida de desarrollo del software.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Recursos para empezar
Más de 10.000 actividades de aprendizaje sobre código seguro: Una década de gestión de riesgos para desarrolladores
Más de 10 000 actividades de aprendizaje de código seguro y una década ayudando a los desarrolladores a reducir riesgos, mejorar la calidad del código y abordar con confianza el desarrollo asistido por IA.
.jpg)
Estableciendo el estándar: SCW publica reglas de seguridad de codificación de IA gratuitas en GitHub
El desarrollo asistido por IA ya no es una posibilidad: ya está aquí y está transformando rápidamente la forma de escribir software. Herramientas como GitHub Copilot, Cline, Roo, Cursor, Aider y Windsurf están transformando a los desarrolladores en sus propios copilotos, permitiendo iteraciones más rápidas y acelerando todo, desde la creación de prototipos hasta grandes proyectos de refactorización.
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
