Analyse approfondie de la vulnérabilité mvcRequestMatcher de Spring

Le 20 mars 2023, les avis de sécurité Spring ont publié un article de blog faisant référence à une vulnérabilité découverte en interne, CVE-2023-20860. Aucune information détaillée n'a été divulguée, si ce n'est qu'il s'agissait d'un problème de contrôle d'accès concernant l'utilisation de mvcMatchers. Les développeurs de Spring ont corrigé le problème et une mise à jour de version est conseillée.

Vous souhaitez une expérience concrète ? Essayez la mission ici.

La sécurité étant notre priorité chez Secure Code Warrior, nous avons décidé d'analyser plus en profondeur cette vulnérabilité mvcRequestMatchers pour identifier l'origine du problème.

Spring fournit l'interface RequestMatcher pour déterminer si une requête correspond à un modèle de chemin. Jetez un œil à l'extrait de code ci-dessous où la méthode d'assistance mvcMatchers est utilisée pour enregistrer les points de terminaison ainsi que leurs exigences d'authentification et d'autorisation. Par exemple, nous pouvons voir que seuls les utilisateurs ayant le rôle ADMIN peuvent accéder au point de terminaison /logs/audit .

MvcMisMatchers ?

Dans Spring, ** est un modèle permettant de faire correspondre n'importe quel nombre de répertoires et de sous-répertoires dans une URL. Par exemple, /bankaccount/** correspondrait à toutes les URL commençant par /bankaccount/, y compris les sous-répertoires tels que /bankaccount/dashboard/settings.

Le modèle * est un modèle qui correspond à n'importe quelle URL et comporte exactement un niveau de sous-répertoire. Par exemple, /bankaccount/* correspondrait à bankaccount/dashboard.

Lors de la configuration des matchers avec *, Spring indique qu'une "incohérence dans la correspondance des modèles entre Spring Security et Spring MVC" s'est produite, créant la vulnérabilité.

Essentiellement, en raison de l'absence de séparateur devant le double caractère générique, le chemin ne correspond pas à une requête entrante, car toutes les requêtes entrantes sont précédées d'une barre oblique. Cela signifie que les règles de contrôle d'accès ne sont pas appliquées, permettant à tout utilisateur non authentifié d'accéder aux ressources.

Jetons un œil au commit qui a corrigé le problème.

Le changement le plus important et le plus visible est l'ajout de la ligne 315, qui corrige le contournement des règles d'autorisation et d'authentification. Il garantit que tout modèle de chemin soumis est précédé d'une barre oblique (/).

404 correspondance introuvable

Lors de l'envoi d'une requête web vers /bankaccounts/view la méthode match analysera et comparera les modèles définis dans le filtre de sécurité avec le chemin demandé. L'analyseur transformera le modèle donné en une arborescence d'éléments de chemin.

L'analyseur lit le premier caractère comme un SeparatorPathElement. Il continue ensuite à lire les caractères de la chaîne jusqu'au séparateur suivant, créant un nouveau LiteralPathElement.

Alors, où est le problème lors de l'utilisation de ** comme modèle ?

Bien qu'il existe de nombreux types d'éléments de chemin, les plus intéressants ici sont le WildcardPathElement et le WildcardTheRestPathElement, avec leurs représentations textuelles respectives : * et /**. 

Un WildcardPathElement correspond à zéro ou plusieurs caractères au sein d'un seul segment de chemin, tandis qu'un WildcardTheRestPathElement correspond à zéro ou plusieurs segments de chemin isolés (séparateurs inclus).

Ce dernier nous donne un indice sur ce qui ne va pas lors de la soumission de ** comme motif. Lors de l'analyse, il recherche des motifs, mais ** ne commence pas par la barre oblique attendue. Au lieu de devenir un WildcardTheRestPathElement, il devient donc deux WildcardPathElements consécutifs.

Ensuite, le motif analysé est utilisé pour correspondre à l'URL demandée. Les chemins doivent commencer par une barre oblique, mais un caractère générique ne correspond pas aux séparateurs.

Cela signifie qu'au lieu d'un RequestMatchResult, une valeur nulle est renvoyée. Par conséquent, les règles de contrôle d'accès appliquées à ce comparateur ne seront pas appliquées à l'URL demandée.

Spring a corrigé le problème en ajoutant une barre oblique au début. En d'autres termes, tout motif ** devient /**, ce qui signifie qu'il peut être analysé comme un WildcardTheRestPathElement, et un RequestMatchResult sera renvoyé car le motif correspond désormais à l'URL demandée.

Vulnérabilité ou mauvaise utilisation de l'API ?

Il est discutable de savoir si cela doit être considéré comme une vulnérabilité, car le code fonctionne comme prévu. Le problème réside essentiellement dans le fait que la documentation de Spring omet de mentionner explicitement que les chemins doivent commencer par un séparateur. Il pourrait donc s'agir davantage d'une mauvaise utilisation de l'API que d'un bug ou d'une vulnérabilité.