Una mirada más de cerca a la vulnerabilidad de Spring mvcRequestMatcher
El 20 de marzo de 2023, Spring Security Advisories publicó una entrada de blog que hacía referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, salvo que se trataba de un problema de control de acceso relacionado con el uso de mvcMatchers. Los desarrolladores de Spring han corregido el problema y se recomienda actualizar la versión.
¿Quiere vivir una experiencia de primera mano? Pruebe la misión aquí.
Como la seguridad es nuestro principal objetivo en Secure Code Warriorhemos decidido profundizar en esta vulnerabilidad de mvcRequestMatchers y averiguar dónde está el problema.
Spring proporciona la interfaz RequestMatcher para determinar si una solicitud coincide con un patrón de ruta. Echa un vistazo al siguiente fragmento de código donde se utiliza el método de ayuda mvcMatchers para registrar los puntos finales junto con sus requisitos de autenticación y autorización. Por ejemplo, podemos ver que sólo los usuarios con el rol ADMIN pueden acceder al endpoint /logs/audit .

¿MvcMisMatchers?
En Spring, ** es un patrón que permite buscar cualquier número de directorios y subdirectorios en una URL. Por ejemplo, /bankaccount/** coincidiría con todas las URL que empiecen por /bankaccount/, incluidos subdirectorios como /bankaccount/dashboard/settings.
El patrón * es un patrón que coincide con cualquier URL y tiene exactamente un nivel de subdirectorio. Por ejemplo, /cuentabancaria/* coincidiría con cuenta bancaria/cuadro de mandos.
Al configurar los matchers con *, Spring afirma que se produjo "un desajuste en la concordancia de patrones entre Spring Security y Spr ing MVC", creando la vulnerabilidad.
Esencialmente, debido a la falta de un separador delante del doble comodín, la ruta no coincide con una solicitud entrante, ya que todas las solicitudes entrantes van precedidas de una barra. Esto significa que las reglas de control de acceso no se aplican y permiten a cualquier usuario no autenticado acceder a los recursos.
Echemos un vistazo al commit que ha solucionado el problema.

El cambio más destacado e importante es la adición de la línea 315, que corrige la omisión de las reglas de autorización y autenticación. Garantiza que cualquier patrón de ruta que se envíe vaya precedido de una barra oblicua (/).
404 coincidencia no encontrada

Al enviar una petición web a /cuentasbancarias/vista , el método match analizará y comparará los patrones definidos en el filtro de seguridad con la ruta solicitada. El analizador sintáctico convertirá el patrón dado en un árbol de elementos de ruta.

El analizador lee el primer carácter como un SeparatorPathElement. A continuación, continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo LiteralPathElement.
Entonces, ¿dónde falla cuando se utiliza ** como patrón?
Aunque existen muchos tipos de elementos de ruta, los más interesantes son WildcardPathElementy WildcardTheRestPathElement, con sus respectivas representaciones de cadena: * y /**.
Un WildcardPathElement coincide con cero o más caracteres dentro de un único segmento de ruta, mientras que un WildcardTheRestPathElement coincide con cero o más segmentos de ruta por sí solos (incluidos los separadores).
Esto último nos da una pista de lo que falla al enviar ** como patrón. Durante el análisis busca patrones, pero ** no empieza con la barra oblicua esperada. Así que en lugar de convertirse en un WildcardTheRestPathElement, se convierte en dos WildcardPathElements consecutivos.
A continuación, el patrón analizado se utiliza para comparar con la URL solicitada. Se espera que las rutas empiecen por una barra oblicua, pero los comodines no coinciden con los separadores.

Esto significa que en lugar de un RequestMatchResult, se devuelve un null. En consecuencia, las reglas de control de acceso establecidas en este comparador no se aplicarán a la URL solicitada.
Spring ha solucionado el problema añadiendo una barra. En otras palabras, cualquier patrón ** se convierte en /**, lo que significa que puede ser analizado como un WildcardTheRestPathElement, y se devolverá un RequestMatchResult ya que el patrón ahora coincide con la URL solicitada.
¿Vulnerabilidad o uso indebido de la API?
Es discutible si esto debería considerarse una vulnerabilidad, ya que el código funciona como se pretende. El problema radica básicamente en el hecho de que la documentación de Spring no menciona explícitamente que las rutas deban comenzar con un separador. Por lo tanto, podría considerarse más un caso de mal uso de la API que un error o vulnerabilidad.


El 20 de marzo de 2023, Spring Security Advisories publicó una entrada en su blog haciendo referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, salvo que se trataba de un problema de control de acceso relacionado con el uso de `mvcMatchers`. Los desarrolladores de Spring han corregido el problema y se recomienda actualizar la versión. Dado que la seguridad es nuestro principal objetivo en Secure Code Warrior, hemos decidido profundizar en esta vulnerabilidad mvcRequestMatchers y averiguar dónde radica el problema principal.

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ónBrysen es desarrollador de software en Secure Code Warrior y se centra en escribir código seguro.


El 20 de marzo de 2023, Spring Security Advisories publicó una entrada de blog que hacía referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, salvo que se trataba de un problema de control de acceso relacionado con el uso de mvcMatchers. Los desarrolladores de Spring han corregido el problema y se recomienda actualizar la versión.
¿Quiere vivir una experiencia de primera mano? Pruebe la misión aquí.
Como la seguridad es nuestro principal objetivo en Secure Code Warriorhemos decidido profundizar en esta vulnerabilidad de mvcRequestMatchers y averiguar dónde está el problema.
Spring proporciona la interfaz RequestMatcher para determinar si una solicitud coincide con un patrón de ruta. Echa un vistazo al siguiente fragmento de código donde se utiliza el método de ayuda mvcMatchers para registrar los puntos finales junto con sus requisitos de autenticación y autorización. Por ejemplo, podemos ver que sólo los usuarios con el rol ADMIN pueden acceder al endpoint /logs/audit .

¿MvcMisMatchers?
En Spring, ** es un patrón que permite buscar cualquier número de directorios y subdirectorios en una URL. Por ejemplo, /bankaccount/** coincidiría con todas las URL que empiecen por /bankaccount/, incluidos subdirectorios como /bankaccount/dashboard/settings.
El patrón * es un patrón que coincide con cualquier URL y tiene exactamente un nivel de subdirectorio. Por ejemplo, /cuentabancaria/* coincidiría con cuenta bancaria/cuadro de mandos.
Al configurar los matchers con *, Spring afirma que se produjo "un desajuste en la concordancia de patrones entre Spring Security y Spr ing MVC", creando la vulnerabilidad.
Esencialmente, debido a la falta de un separador delante del doble comodín, la ruta no coincide con una solicitud entrante, ya que todas las solicitudes entrantes van precedidas de una barra. Esto significa que las reglas de control de acceso no se aplican y permiten a cualquier usuario no autenticado acceder a los recursos.
Echemos un vistazo al commit que ha solucionado el problema.

El cambio más destacado e importante es la adición de la línea 315, que corrige la omisión de las reglas de autorización y autenticación. Garantiza que cualquier patrón de ruta que se envíe vaya precedido de una barra oblicua (/).
404 coincidencia no encontrada

Al enviar una petición web a /cuentasbancarias/vista , el método match analizará y comparará los patrones definidos en el filtro de seguridad con la ruta solicitada. El analizador sintáctico convertirá el patrón dado en un árbol de elementos de ruta.

El analizador lee el primer carácter como un SeparatorPathElement. A continuación, continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo LiteralPathElement.
Entonces, ¿dónde falla cuando se utiliza ** como patrón?
Aunque existen muchos tipos de elementos de ruta, los más interesantes son WildcardPathElementy WildcardTheRestPathElement, con sus respectivas representaciones de cadena: * y /**.
Un WildcardPathElement coincide con cero o más caracteres dentro de un único segmento de ruta, mientras que un WildcardTheRestPathElement coincide con cero o más segmentos de ruta por sí solos (incluidos los separadores).
Esto último nos da una pista de lo que falla al enviar ** como patrón. Durante el análisis busca patrones, pero ** no empieza con la barra oblicua esperada. Así que en lugar de convertirse en un WildcardTheRestPathElement, se convierte en dos WildcardPathElements consecutivos.
A continuación, el patrón analizado se utiliza para comparar con la URL solicitada. Se espera que las rutas empiecen por una barra oblicua, pero los comodines no coinciden con los separadores.

Esto significa que en lugar de un RequestMatchResult, se devuelve un null. En consecuencia, las reglas de control de acceso establecidas en este comparador no se aplicarán a la URL solicitada.
Spring ha solucionado el problema añadiendo una barra. En otras palabras, cualquier patrón ** se convierte en /**, lo que significa que puede ser analizado como un WildcardTheRestPathElement, y se devolverá un RequestMatchResult ya que el patrón ahora coincide con la URL solicitada.
¿Vulnerabilidad o uso indebido de la API?
Es discutible si esto debería considerarse una vulnerabilidad, ya que el código funciona como se pretende. El problema radica básicamente en el hecho de que la documentación de Spring no menciona explícitamente que las rutas deban comenzar con un separador. Por lo tanto, podría considerarse más un caso de mal uso de la API que un error o vulnerabilidad.

El 20 de marzo de 2023, Spring Security Advisories publicó una entrada de blog que hacía referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, salvo que se trataba de un problema de control de acceso relacionado con el uso de mvcMatchers. Los desarrolladores de Spring han corregido el problema y se recomienda actualizar la versión.
¿Quiere vivir una experiencia de primera mano? Pruebe la misión aquí.
Como la seguridad es nuestro principal objetivo en Secure Code Warriorhemos decidido profundizar en esta vulnerabilidad de mvcRequestMatchers y averiguar dónde está el problema.
Spring proporciona la interfaz RequestMatcher para determinar si una solicitud coincide con un patrón de ruta. Echa un vistazo al siguiente fragmento de código donde se utiliza el método de ayuda mvcMatchers para registrar los puntos finales junto con sus requisitos de autenticación y autorización. Por ejemplo, podemos ver que sólo los usuarios con el rol ADMIN pueden acceder al endpoint /logs/audit .

¿MvcMisMatchers?
En Spring, ** es un patrón que permite buscar cualquier número de directorios y subdirectorios en una URL. Por ejemplo, /bankaccount/** coincidiría con todas las URL que empiecen por /bankaccount/, incluidos subdirectorios como /bankaccount/dashboard/settings.
El patrón * es un patrón que coincide con cualquier URL y tiene exactamente un nivel de subdirectorio. Por ejemplo, /cuentabancaria/* coincidiría con cuenta bancaria/cuadro de mandos.
Al configurar los matchers con *, Spring afirma que se produjo "un desajuste en la concordancia de patrones entre Spring Security y Spr ing MVC", creando la vulnerabilidad.
Esencialmente, debido a la falta de un separador delante del doble comodín, la ruta no coincide con una solicitud entrante, ya que todas las solicitudes entrantes van precedidas de una barra. Esto significa que las reglas de control de acceso no se aplican y permiten a cualquier usuario no autenticado acceder a los recursos.
Echemos un vistazo al commit que ha solucionado el problema.

El cambio más destacado e importante es la adición de la línea 315, que corrige la omisión de las reglas de autorización y autenticación. Garantiza que cualquier patrón de ruta que se envíe vaya precedido de una barra oblicua (/).
404 coincidencia no encontrada

Al enviar una petición web a /cuentasbancarias/vista , el método match analizará y comparará los patrones definidos en el filtro de seguridad con la ruta solicitada. El analizador sintáctico convertirá el patrón dado en un árbol de elementos de ruta.

El analizador lee el primer carácter como un SeparatorPathElement. A continuación, continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo LiteralPathElement.
Entonces, ¿dónde falla cuando se utiliza ** como patrón?
Aunque existen muchos tipos de elementos de ruta, los más interesantes son WildcardPathElementy WildcardTheRestPathElement, con sus respectivas representaciones de cadena: * y /**.
Un WildcardPathElement coincide con cero o más caracteres dentro de un único segmento de ruta, mientras que un WildcardTheRestPathElement coincide con cero o más segmentos de ruta por sí solos (incluidos los separadores).
Esto último nos da una pista de lo que falla al enviar ** como patrón. Durante el análisis busca patrones, pero ** no empieza con la barra oblicua esperada. Así que en lugar de convertirse en un WildcardTheRestPathElement, se convierte en dos WildcardPathElements consecutivos.
A continuación, el patrón analizado se utiliza para comparar con la URL solicitada. Se espera que las rutas empiecen por una barra oblicua, pero los comodines no coinciden con los separadores.

Esto significa que en lugar de un RequestMatchResult, se devuelve un null. En consecuencia, las reglas de control de acceso establecidas en este comparador no se aplicarán a la URL solicitada.
Spring ha solucionado el problema añadiendo una barra. En otras palabras, cualquier patrón ** se convierte en /**, lo que significa que puede ser analizado como un WildcardTheRestPathElement, y se devolverá un RequestMatchResult ya que el patrón ahora coincide con la URL solicitada.
¿Vulnerabilidad o uso indebido de la API?
Es discutible si esto debería considerarse una vulnerabilidad, ya que el código funciona como se pretende. El problema radica básicamente en el hecho de que la documentación de Spring no menciona explícitamente que las rutas deban comenzar con un separador. Por lo tanto, podría considerarse más un caso de mal uso de la API que un error o vulnerabilidad.

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
Pruebe nuestra misión para experimentar por sí mismo el impacto y aprenda a evitar cometer un error similar.
Pruébelo ahoraBrysen es desarrollador de software en Secure Code Warrior y se centra en escribir código seguro.
El 20 de marzo de 2023, Spring Security Advisories publicó una entrada de blog que hacía referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, salvo que se trataba de un problema de control de acceso relacionado con el uso de mvcMatchers. Los desarrolladores de Spring han corregido el problema y se recomienda actualizar la versión.
¿Quiere vivir una experiencia de primera mano? Pruebe la misión aquí.
Como la seguridad es nuestro principal objetivo en Secure Code Warriorhemos decidido profundizar en esta vulnerabilidad de mvcRequestMatchers y averiguar dónde está el problema.
Spring proporciona la interfaz RequestMatcher para determinar si una solicitud coincide con un patrón de ruta. Echa un vistazo al siguiente fragmento de código donde se utiliza el método de ayuda mvcMatchers para registrar los puntos finales junto con sus requisitos de autenticación y autorización. Por ejemplo, podemos ver que sólo los usuarios con el rol ADMIN pueden acceder al endpoint /logs/audit .

¿MvcMisMatchers?
En Spring, ** es un patrón que permite buscar cualquier número de directorios y subdirectorios en una URL. Por ejemplo, /bankaccount/** coincidiría con todas las URL que empiecen por /bankaccount/, incluidos subdirectorios como /bankaccount/dashboard/settings.
El patrón * es un patrón que coincide con cualquier URL y tiene exactamente un nivel de subdirectorio. Por ejemplo, /cuentabancaria/* coincidiría con cuenta bancaria/cuadro de mandos.
Al configurar los matchers con *, Spring afirma que se produjo "un desajuste en la concordancia de patrones entre Spring Security y Spr ing MVC", creando la vulnerabilidad.
Esencialmente, debido a la falta de un separador delante del doble comodín, la ruta no coincide con una solicitud entrante, ya que todas las solicitudes entrantes van precedidas de una barra. Esto significa que las reglas de control de acceso no se aplican y permiten a cualquier usuario no autenticado acceder a los recursos.
Echemos un vistazo al commit que ha solucionado el problema.

El cambio más destacado e importante es la adición de la línea 315, que corrige la omisión de las reglas de autorización y autenticación. Garantiza que cualquier patrón de ruta que se envíe vaya precedido de una barra oblicua (/).
404 coincidencia no encontrada

Al enviar una petición web a /cuentasbancarias/vista , el método match analizará y comparará los patrones definidos en el filtro de seguridad con la ruta solicitada. El analizador sintáctico convertirá el patrón dado en un árbol de elementos de ruta.

El analizador lee el primer carácter como un SeparatorPathElement. A continuación, continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo LiteralPathElement.
Entonces, ¿dónde falla cuando se utiliza ** como patrón?
Aunque existen muchos tipos de elementos de ruta, los más interesantes son WildcardPathElementy WildcardTheRestPathElement, con sus respectivas representaciones de cadena: * y /**.
Un WildcardPathElement coincide con cero o más caracteres dentro de un único segmento de ruta, mientras que un WildcardTheRestPathElement coincide con cero o más segmentos de ruta por sí solos (incluidos los separadores).
Esto último nos da una pista de lo que falla al enviar ** como patrón. Durante el análisis busca patrones, pero ** no empieza con la barra oblicua esperada. Así que en lugar de convertirse en un WildcardTheRestPathElement, se convierte en dos WildcardPathElements consecutivos.
A continuación, el patrón analizado se utiliza para comparar con la URL solicitada. Se espera que las rutas empiecen por una barra oblicua, pero los comodines no coinciden con los separadores.

Esto significa que en lugar de un RequestMatchResult, se devuelve un null. En consecuencia, las reglas de control de acceso establecidas en este comparador no se aplicarán a la URL solicitada.
Spring ha solucionado el problema añadiendo una barra. En otras palabras, cualquier patrón ** se convierte en /**, lo que significa que puede ser analizado como un WildcardTheRestPathElement, y se devolverá un RequestMatchResult ya que el patrón ahora coincide con la URL solicitada.
¿Vulnerabilidad o uso indebido de la API?
Es discutible si esto debería considerarse una vulnerabilidad, ya que el código funciona como se pretende. El problema radica básicamente en el hecho de que la documentación de Spring no menciona explícitamente que las rutas deban comenzar con un separador. Por lo tanto, podría considerarse más un caso de mal uso de la API que un error o vulnerabilidad.
Índice

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.