Un análisis más detallado de la vulnerabilidad MVC RequestMatcher Spring

El 20 de marzo de 2023, Spring Security Advisories publicó un entrada de blog haciendo referencia a una vulnerabilidad descubierta internamente, CVE-2023-20860. No se reveló información detallada, excepto que se trataba de un problema de control de acceso relacionado con el uso de Matchers de MVC. Los desarrolladores de Spring han solucionado el problema y se recomienda actualizar la versión.

¿Quieres una experiencia de primera mano? Prueba la misión aquí.

Dado que la seguridad es nuestro principal objetivo en Secure Code Warrior, decidimos profundizar en esta vulnerabilidad de MVCRequestMatchers y averiguar cuál es el problema principal.

Spring proporciona la interfaz RequestMatcher para determinar si una solicitud coincide con un patrón de ruta. Eche un vistazo al fragmento de código que aparece a continuación, donde Matchers de MVC el método helper se utiliza para registrar los puntos finales junto con sus requisitos de autenticación y autorización. Por ejemplo, podemos ver que solo los usuarios con el rol de ADMINISTRADOR pueden acceder al /logs/auditoría punto final.

MvcSrta.¿Emparejadores?

En primavera, ** es un patrón para hacer coincidir cualquier número de directorios y subdirectorios de una URL. Por ejemplo,/cuenta bancaria/** coincidiría con todas las URL que comiencen por /cuenta bancaria/, incluidos subdirectorios como /cuenta bancaria/panel de control/configuración.

El * el patrón es un patrón que coincide con cualquier URL y tiene exactamente un nivel de subdirectorio. Por ejemplo, /cuenta bancaria/ * coincidiría cuenta bancaria/panel de control.

Al configurar los comparadores con *, Spring afirma que «una falta de coincidencia en la coincidencia de patrones entre Spring Security y Spring MVC» tuvo lugar, creando la vulnerabilidad.

Básicamente, debido a la falta de un separador delante del comodín doble, la ruta no coincide con una solicitud entrante, ya que todas las solicitudes entrantes van precedidas de una barra diagonal. Esto significa que las reglas de control de acceso no se aplican y permite que cualquier usuario no autenticado acceda a los recursos.

Vamos a echar un vistazo a la cometer eso solucionó 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 diagonal (/).

404 coincidencias no encontradas

Al enviar una solicitud web a /cuentas bancarias/ver la concuerda El método analizará y comparará los patrones definidos en el filtro de seguridad con la ruta solicitada. El analizador convertirá el patrón dado en un árbol de elementos de ruta.

El analizador lee el primer carácter como Elemento Separator Path. Luego continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo Elemento LiteralPath.

Entonces, ¿dónde sale mal cuando se usa? ** como patrón?

Si bien hay muchos tipos de elementos de ruta, los más interesantes aquí son los Pathelemen comodínt y el Comodín: el elemento RestPath, con sus respectivas representaciones de cadenas: * y /**. 

UN Elemento WildcardPath coincide con cero o más caracteres dentro de un solo segmento de ruta, mientras que un Comodín: el elemento RestPath coincide con cero o más segmentos de ruta por sí solos (incluidos los separadores).

Este último nos da una pista de lo que sale mal al enviar ** como patrón. Durante el análisis, busca patrones, pero ** no comienza con la barra oblicua esperada. Entonces, en lugar de convertirse en Comodín: el elemento RestPath, se convierte en dos consecutivos Elementos de Wildcard Path.

A continuación, el patrón analizado se usa para compararlo con la URL solicitada. Se espera que las rutas comiencen con una barra diagonal, pero un comodín no coincide con los separadores.

Esto significa que en lugar de un Solicitar resultado de la coincidencia, se devuelve un valor nulo. Por lo tanto, las reglas de control de acceso establecidas en este comparador no se aplicarán a la URL solicitada.

Spring solucionó el problema anteponiendo una barra. En otras palabras, cualquier ** el patrón se convierte /**, lo que significa que se puede analizar como Comodín: el elemento RestPath, y un Solicitar resultado de la coincidencia se devolverá ya que el patrón coincide ahora con la URL solicitada.

¿Vulnerabilidad o uso indebido de API?

Es discutible si esto debe considerarse una vulnerabilidad, ya que el código funciona según lo previsto. El problema radica básicamente en el hecho de que el Documentación de primavera carece de una mención explícita de que las rutas deben comenzar con un separador. Por lo tanto, podría considerarse más un caso de uso indebido de la API que un error o una vulnerabilidad.