Autorisation défaillante

L’authentification prouve qui vous êtes. L’autorisation détermine ce que vous avez le droit de faire.

Une autorisation défaillante signifie que le système permet aux utilisateurs de faire ou de voir des choses qu’ils ne devraient pas pouvoir faire ou voir.

BOLA signifie autorisation défaillante au niveau des objets.

Il s’agit du principal risque lié aux API : une API vérifie que vous êtes connecté, mais pas que l’objet précis que vous demandez vous appartient réellement.

Imaginez que votre compte soit l’utilisateur 100.

Si vous modifiez l’ID et que le serveur répond toujours, vous venez de lire les commandes d’une autre personne. C’est un cas de BOLA.

Les développeurs font souvent confiance à l’identifiant fourni dans la requête.

Ils oublient de vérifier que l’utilisateur connecté possède réellement l’objet concerné. La solution consiste à vérifier la propriété à chaque requête.

Une autre faille est BFLA : autorisation défaillante au niveau des fonctions.

Un utilisateur normal appelle une action réservée aux administrateurs et celle-ci fonctionne, car le point de terminaison ne vérifie jamais le rôle de l’utilisateur.

Examinez une route réservée aux administrateurs :

Si un utilisateur ordinaire peut l’appeler avec succès, l’API n’a pas appliqué correctement le contrôle d’accès fondé sur les rôles.

Certaines API associent aveuglément les champs d’une requête à ceux d’un enregistrement.

Un utilisateur pourrait ajouter un champ comme role=admin à une mise à jour de profil et élever discrètement ses propres privilèges.

Ne comptez jamais sur l’interface utilisateur pour masquer des boutons ou des champs.

Le serveur doit appliquer chaque décision d’autorisation, car les attaquants envoient directement des requêtes et contournent entièrement votre interface.

Les identifiants séquentiels rendent BOLA facile à exploiter.

L’utilisation d’identifiants aléatoires comme un UUID ne remplace pas les vérifications d’autorisation, mais elle élimine l’attaque simple qui consiste à deviner le nombre suivant.

Une API sécurisée refuse l’accès par défaut.

L’accès n’est autorisé que lorsqu’une règle explicite l’accorde. Ainsi, une vérification oubliée échoue en refusant l’accès plutôt qu’en divulguant des données.

Les failles d’autorisation sont faciles à dissimuler, alors testez-les volontairement.

Essayez d’accéder aux données d’un autre utilisateur avec votre propre jeton. Si cela fonctionne, vous avez découvert une faille grave à corriger.

Une API confirme que vous êtes connecté, mais renvoie l’enregistrement d’un autre utilisateur lorsque vous modifiez l’ID. De quelle faille s’agit-il ?

Une autorisation défaillante permet aux utilisateurs d’accéder à ce qu’ils ne devraient pas voir. Soyez attentif à BOLA, à BFLA et à l’affectation en masse.

Appliquez les vérifications de propriété et de rôle sur le serveur, refusez l’accès par défaut et testez volontairement l’autorisation.