Un análisis detallado de la vulnerabilidad mvcRequestMatcher de Spring

El 20 de marzo de 2023, Spring Security Advisories publicó una entrada de blog sobre 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 solucionado el problema y se recomienda actualizar la versión.

¿Le gustaría vivir una experiencia de primera mano? Pruebe 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 dónde reside 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 a continuación donde se utiliza el método auxiliar mvcMatchers 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 ADMIN pueden acceder al punto final /logs/audit .

¿MvcMisMatchers?

En Spring, ** es un patrón para hacer coincidir cualquier número de directorios y subdirectorios en una URL. Por ejemplo, /bankaccount/** coincidiría con todas las URL que comienzan con /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, /bankaccount/* coincidiría con bankaccount/dashboard.

Al configurar los comparadores con *, Spring afirma que se produjo "una falta de coincidencia en la correspondencia de patrones entre Spring Security y Spring MVC", lo que creó la vulnerabilidad.

Esencialmente, 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, permitiendo que cualquier usuario no autenticado acceda a los recursos.

Echemos un vistazo al commit que solucionó el problema.

El cambio más destacado e importante es la adición de la línea 315, que soluciona 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 coincidencia no encontrada

Al enviar una solicitud web a /bankaccounts/view el método match 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 un SeparatorPathElement. Luego continúa leyendo los caracteres de la cadena hasta el siguiente separador, creando un nuevo LiteralPathElement.

Entonces, ¿dónde está el error al usar ** como patrón?

Aunque existen muchos tipos de elementos de ruta, los más interesantes aquí son WildcardPathElement y 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í mismos (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 diagonal esperada. Por lo tanto, en lugar de convertirse en un WildcardTheRestPathElement, se convierte en dos WildcardPathElements consecutivos.

A continuación, el patrón analizado se utiliza para buscar coincidencias 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 RequestMatchResult, se devuelve un valor nulo. En consecuencia, las reglas de control de acceso aplicadas a este comparador no se aplicarán a la URL solicitada.

Spring solucionó el problema anteponiendo una barra diagonal. En otras palabras, cualquier patrón ** se convierte en /**, lo que significa que puede analizarse 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 debe considerarse una vulnerabilidad, ya que el código funciona según lo previsto. El problema radica básicamente en que la documentación de Spring 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.