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é.
Le 20 mars 2023, Spring Security Advisories a 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, sauf 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 résolu le problème et une mise à jour de version est conseillée. La sécurité étant au cœur de nos préoccupations chez Secure Code Warrior, nous avons décidé d'approfondir cette vulnérabilité de MvcRequestMatchers et de déterminer où se situe le problème principal.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
Brysen est développeur de logiciels chez Secure Code Warrior et se concentre sur l'écriture de code sécurisé.
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é.
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é.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
Essayez notre mission pour en ressentir l'impact par vous-même et découvrez comment éviter de commettre une erreur similaire.
Essayez-le dès maintenantBrysen est développeur de logiciels chez Secure Code Warrior et se concentre sur l'écriture de code sécurisé.
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é.
Table des matières
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
