Un examen plus approfondi de la vulnérabilité MvcRequestMatcher Spring

Le 20 mars 2023, Spring Security Advisories a publié un billet de blog référencer 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 Matchers MVC. Les développeurs de Spring ont résolu le problème et une mise à jour de version est conseillée.

Vous souhaitez vivre une expérience de première main ? Testez la mission ici.

La sécurité étant au cœur de nos préoccupations Secure Code Warrior, nous avons décidé de nous pencher plus en profondeur sur cette vulnérabilité de MvcRequestMatchers et de déterminer où se situe le problème principal.

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

MvcMissDes allumeurs ?

Au printemps, ** est un modèle permettant de faire correspondre un nombre quelconque de répertoires et de sous-répertoires dans une URL. Par exemple,/compte bancaire/** correspondrait à toutes les URL commençant par /compte bancaire/, y compris des sous-répertoires tels que /compte/tableau de bord/paramètres.

Le * pattern est un modèle qui correspond à n'importe quelle URL et possède exactement un niveau de sous-répertoire. Par exemple, /compte bancaire/ * correspondrait compte bancaire/tableau de bord.

Lors de la configuration des matchers avec *, Spring déclare que « une incompatibilité dans la correspondance des modèles entre Spring Security et Spring MVC » a eu lieu, 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 demande entrante car toutes les demandes 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 et que tout utilisateur non authentifié peut accéder aux ressources.

Jetons un coup d'œil au commettre cela a résolu le problème.

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

404 résultats non trouvés

Lorsque vous envoyez une demande Web à /comptes-bancaires/voir le correspondre La méthode analysera et comparera les modèles définis dans le filtre de sécurité avec le chemin demandé. L'analyseur transformera le motif donné en un arbre d'éléments de chemin.

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

Alors, où se passe-t-il mal lors de l'utilisation ** comme modèle ?

Bien qu'il existe de nombreux types d'éléments de chemin, les plus intéressants sont les Élément Wildcard Patht et le Élément Wildcard The Rest Path, avec leurs représentations sous forme de chaîne respectives : * et /**. 

UNE Élément WildcardPath correspond à zéro ou plusieurs caractères dans un seul segment de chemin, tandis qu'un Élément Wildcard The Rest Path correspond à zéro ou plusieurs segments de chemin à eux seuls (y compris les séparateurs).

Ce dernier nous donne une idée de ce qui ne va pas lors de la soumission ** comme modèle. Pendant l'analyse, il recherche des modèles, mais ** ne commence pas par la barre oblique prévue. Ainsi, au lieu de devenir Élément Wildcard The Rest Path, cela devient deux consécutifs Éléments Wildcard Path.

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

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

Spring a résolu le problème en ajoutant une barre oblique. En d'autres termes, n'importe quel ** le motif devient /**, ce qui signifie qu'il peut être analysé comme Élément Wildcard The Rest Path, et un Résultat de la demande de match sera renvoyé car le modèle correspond désormais à l'URL demandée.

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

On peut se demander 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 Documentation de printemps ne contient aucune mention explicite selon laquelle les chemins doivent commencer par un séparateur. Par conséquent, il pourrait s'agir davantage d'un cas d'utilisation abusive de l'API que d'un bogue ou d'une vulnérabilité.