Série OWASP Top 10 API : Maîtriser la sécurité - Autorisation défaillante au niveau de l'objet

Les menaces en matière de cybersécurité sont aujourd'hui omniprésentes et incessantes. La situation est devenue telle qu'il est presque impossible de les contrer une fois les programmes déployés. Cependant, à l'ère du DevSecOps, de la livraison continue et de l'abondance de données, les organisations avisées aident leurs développeurs à monter en compétences pour devenir des experts en sécurité, capables d'éliminer les vulnérabilités courantes avant même qu'elles n'atteignent la production. Nous avons déjà abordé les vulnérabilités web, ainsi que nos propres 8 principales failles d'Infrastructure as Code, et il est maintenant temps de découvrir le prochain défi majeur de la sécurité logicielle. Êtes-vous prêt ?

Cette nouvelle série d'articles se concentrera sur certaines des pires failles de sécurité liées aux interfaces de programmation d'applications (API). Elles sont si critiques qu'elles figurent dans le classement des principales vulnérabilités API de l'Open Web Application Security Project (OWASP). Compte tenu de l'importance des API dans les infrastructures informatiques modernes, il est impératif de les bannir de vos applications et programmes à tout prix.

L'examen de la vulnérabilité d'autorisation au niveau de l'objet illustre parfaitement pourquoi il est essentiel d'utiliser le code pour renforcer la sécurité. Cette faille survient lorsque les développeurs omettent de définir explicitement quels utilisateurs sont autorisés à consulter des objets et des données, ou ne prévoient aucune vérification pour visualiser, modifier ou manipuler ces objets. Cela permet à des tiers d'accéder aux données via les points de terminaison (endpoints) de l'API. Un point de terminaison est un point de contact, souvent une URL, utilisé pour la communication entre l'API et un autre système. Si la connectivité entre les applications a permis l'essor des logiciels les plus populaires au monde, elle comporte le risque d'exposer de multiples points de terminaison s'ils ne sont pas parfaitement sécurisés.

Elle peut également se produire lorsque les développeurs oublient ou héritent de propriétés de classes parentes sans réaliser que cela omet un processus de vérification critique dans leur code. En règle générale, des contrôles d'autorisation au niveau de l'objet doivent être inclus dans chaque fonction accédant à une source de données à partir d'une entrée utilisateur.

Vous pensez maîtriser le sujet et être capable de détecter, corriger et éliminer une faille de contrôle d'accès dès maintenant ? Relevez le défi ludique :

Quel a été votre résultat ? Si vous souhaitez améliorer votre score, continuez votre lecture !

Quels sont quelques exemples de vulnérabilités liées à une autorisation défaillante au niveau de l'objet ?

Les vulnérabilités de contrôle d'accès au niveau de l'objet permettent aux attaquants d'effectuer des actions qui leur sont normalement interdites. Il peut s'agir d'actions réservées aux administrateurs, comme l'accès à des données sensibles ou la suppression d'enregistrements. Dans un environnement hautement sécurisé, cela peut même signifier empêcher quiconque de consulter des enregistrements sans autorisation spécifique.
Vous devez garder à l'esprit toutes les actions possibles lors de la définition de l'autorisation au niveau de l'objet. Par exemple, dans une API Java Spring, un point de terminaison potentiellement vulnérable pourrait ressembler à ceci :

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

Le point de terminaison de l'API supprime les commandes par ID, mais ne vérifie pas si cette commande a été passée par l'utilisateur actuellement connecté. Cela offre à un attaquant l'opportunité d'exploiter cette faille pour supprimer les commandes d'autres utilisateurs.

Pour mettre en œuvre correctement des restrictions d'accès sécurisées, le code devrait plutôt ressembler à ceci :

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Éliminer les vulnérabilités d'autorisation défaillante au niveau de l'objet

Le code de contrôle d'accès n'a pas besoin d'être excessivement complexe. Dans l'exemple de notre environnement API Java Spring, il peut être corrigé en définissant précisément qui est autorisé à accéder aux objets.

Tout d'abord, un processus de vérification doit être mis en œuvre afin d'identifier qui effectue la requête :

User user = userService.getUserByContext();

Ensuite, nous devons vérifier que l'identifiant de l'objet existe et appartient bien à l'utilisateur qui effectue la requête :

boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));

Enfin, nous procédons à la suppression de l'objet :

orderRepository.deleteById(id);

Gardez à l'esprit que la méthode d'autorisation utilisée dans votre code doit être conforme aux politiques utilisateurs et aux contrôles d'accès aux données de votre organisation. Pour garantir une sécurité optimale, effectuez des vérifications afin de vous assurer que les utilisateurs disposent des accès nécessaires à leurs fonctions, tout en étant restreints sur les données sensibles. Cela permet de détecter d'éventuelles vulnérabilités de contrôle d'objet qui auraient pu être négligées.

L'essentiel à retenir de ces exemples est de définir systématiquement chaque action possible sur un objet, puis d'intégrer des contrôles d'accès robustes directement dans le code. Enfin, ne vous fiez jamais aux propriétés héritées des parents pour gérer ces accès ou déléguer cette autorité. Définissez plutôt explicitement les permissions et les actions utilisateur dans le code pour chaque type d'objet à protéger.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre d'autres failles de sécurité. Vous pouvez également demander une démonstration de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.