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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
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.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
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.
