Les codeurs conquièrent la série des 10 meilleures API de l'OWASP en matière de sécurité : autorisation au niveau des objets cassés

De nos jours, les menaces à la cybersécurité sont omniprésentes et incessantes. La situation s'est tellement aggravée qu'il est devenu presque impossible d'essayer de les suivre après le déploiement des programmes. Cependant, à l'ère du DevSecOps, de la diffusion continue et de l'augmentation des revenus liés aux données, les organisations astucieuses aident leurs développeurs à améliorer leurs compétences pour devenir des superstars sensibles à la sécurité qui les aident à éliminer les vulnérabilités courantes avant même qu'elles ne soient mises en production. Nous avons abordé vulnérabilités du Web, ainsi que notre propre Les 8 meilleures infrastructures en tant que code bugs, et il est maintenant temps de se familiariser avec le prochain grand défi en matière de sécurité logicielle. Es-tu prêt ?

Cette prochaine série de blogs se concentrera sur certains des pires bogues de sécurité liés aux interfaces de programmation d'applications (API). Ils sont si mauvais qu'ils ont créé l'Open Web Application Security Project (GUÊPE) liste des principales vulnérabilités des API. Compte tenu de l'importance des API pour les infrastructures informatiques modernes, il s'agit de problèmes critiques que vous devez à tout prix éviter dans vos applications et programmes.

Un exemple parfait de la raison pour laquelle il est essentiel d'utiliser du code pour renforcer la sécurité peut être trouvé dans l'examen de la vulnérabilité d'autorisation au niveau des objets cassés. Cela se produit lorsque les programmeurs ne définissent pas explicitement quels utilisateurs peuvent visualiser des objets et des données, ou ne fournissent aucune forme de vérification pour afficher, modifier ou effectuer d'autres demandes pour manipuler des objets ou y accéder, ce qui leur permet de modifier et d'accéder aux objets et aux données via les points de terminaison de l'API. Un point de terminaison d'API est un point de contact, souvent une URL, utilisé pour la communication entre l'API elle-même et un autre système. La capacité de connectivité entre les applications a amélioré certains des logiciels les plus appréciés au monde, mais elle risque d'exposer plusieurs terminaux s'ils ne sont pas étanches.

Cela peut également se produire lorsque les codeurs oublient ou héritent des propriétés des classes parentes, sans se rendre compte que cela exclut également un processus de vérification critique dans leur code. En général, des contrôles d'autorisation au niveau de l'objet doivent être inclus pour chaque fonction qui accède à une source de données à l'aide d'une entrée de l'utilisateur.

Vous pensez les connaître déjà et pouvoir détecter, corriger et éliminer un bogue de contrôle d'accès dès maintenant ? Jouez au défi gamifié :

Comment t'es-tu débrouillé ? Si tu veux travailler sur ta partition, continue à lire !

Quels sont quelques exemples de vulnérabilités d'autorisation au niveau de l'objet non respectées ?

Les vulnérabilités de contrôle d'accès au niveau des objets permettent aux attaquants de prendre des mesures qu'ils ne devraient pas être autorisés à effectuer. Il peut s'agir d'une action qui devrait être réservée aux administrateurs, comme l'accès ou la visualisation de données sensibles, ou la destruction d'enregistrements. Dans un environnement hautement sécurisé, cela peut même signifier empêcher quiconque de consulter les enregistrements à moins d'y être spécifiquement autorisé.
Vous devez tenir compte de toutes les actions possibles lorsque vous définissez l'autorisation au niveau de l'objet. Par exemple, dans l'API Java Spring, un point de terminaison présentant un problème potentiel peut ressembler à ceci :

public boolean DeleteOrder (ID long) {
Ordre de commande = OrderRepository.getOne (id) ;
si (ordre == nul) {
log.info (« Ordre introuvable ») ;
renvoie faux ;
}
Utilisateur user = Order.getUser () ;
OrderRepository.delete (ordre) ;
log.info (« Supprimer la commande pour l'utilisateur {} », User.getId ()) ;
retourne vrai ;

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

Pour que les restrictions d'accès sécurisé soient correctement mises en œuvre, le code devrait ressembler à ceci :

public boolean DeleteOrder (ID long) {
Utilisateur utilisateur = UserService.getUserByContext () ;
booléen OrderExist = getUserOrders () .stream ()
.anyMatch (commande -> (Order.getId () == id)) ;
si (OrderExist) {
OrderRepository.deleteById (id) ;
log.info (« Supprimer la commande pour l'utilisateur {} », User.getId ()) ;
retourne vrai ;
} autre {
log.info (« Ordre introuvable ») ;
renvoie faux ;

Élimination des vulnérabilités liées à l'autorisation au niveau de l'objet

Le code de contrôle d'accès n'a pas besoin d'être trop compliqué. Dans le cas de notre exemple d'environnement d'API Java Spring, il est possible de résoudre ce problème en définissant précisément qui peut accéder aux objets.

Tout d'abord, un processus de vérification doit être mis en place afin d'identifier l'auteur de la demande :

Utilisateur utilisateur = UserService.getUserByContext () ;

Ensuite, nous devons nous assurer que l'identifiant de l'objet existe et qu'il appartient à l'utilisateur qui fait la demande :

booléen OrderExist = getUserOrders () .stream ()
.anyMatch (commande -> (Order.getId () == id)) ;

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

OrderRepository.deleteById (id) ;

N'oubliez pas que vous devez vous assurer que la méthode d'autorisation de votre code est conforme aux politiques des utilisateurs et aux contrôles d'accès aux données de votre organisation. Afin de vous assurer que votre code est totalement sécurisé, vous devez vérifier que les utilisateurs disposant de différents niveaux d'autorisation ont accès aux données dont ils ont besoin pour effectuer leur travail, mais qu'ils ne peuvent pas consulter ou modifier tout ce qui devrait leur être réservé. Cela pourrait révéler des vulnérabilités de contrôle d'objets manquantes qui ont été accidentellement négligées.

Les principaux enseignements de ces exemples sont de définir d'abord toutes les actions qu'un utilisateur peut effectuer avec un objet, puis d'ajouter des contrôles d'accès puissants directement au code. Enfin, ne vous fiez jamais aux propriétés parentes héritées pour effectuer ce travail ou pour déléguer cette autorité à un autre endroit. Définissez plutôt les autorisations et les actions des utilisateurs dans le code de manière explicite pour chaque type d'objet à protéger.

Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.