Autorisation de niveau objet cassée avec des exemples

Dans cet article, nous explorons et discutons de l'échec de l'autorisation au niveau des objets cassés.

Nous allons commencer par expliquer ce que signifie l'autorisation au niveau de l'objet cassé. Ensuite, nous passerons par l'attaque en expliquant les facteurs de risque associés.

Nous examinerons ensuite certains des impacts possibles de la vulnérabilité avant de nous pencher enfin sur les défenses courantes.




Qu'est-ce que l'autorisation au niveau des objets cassés?

En bref, ce type d’attaque signifie que l’autorisation appliquée aux données ne se fait pas comme elle le devrait. Cela conduit à accorder l'accès aux ressources et aux données alors qu'il ne devrait pas l'être.

Dans le passé, l'autorisation de niveau objet cassée était connue sous le nom de référence d'objet directe non sécurisée (IDOR).


Quand on dit le mot objet dans Autorisation au niveau des objets cassés, ce que nous entendons est une valeur ou un groupe de valeurs. Un objet peut être une publication sur les réseaux sociaux contenant l'auteur, le contenu et la date de publication.

Autorisation est tout ce à quoi un utilisateur est autorisé à accéder. Par conséquent, nous parlons d'un utilisateur déjà connecté.

Lorsqu'un utilisateur fait une demande à une API, la demande est utilisée pour accéder aux objets. C'est sur ce point qu'une décision doit être prise concernant l'autorisation. L'utilisateur ne doit pouvoir accéder qu'aux objets auxquels il a été autorisé à accéder. Cette autorisation fonctionne correctement.


Lorsque l'autorisation est rompue, les utilisateurs sont autorisés à accéder à des données et à des ressources auxquelles ils ne devraient pas être autorisés.

Une API facilite diverses opérations sur les objets. Nous pouvons obtenir, créer, mettre à jour ou même supprimer des objets.

Interagir avec un objet est tout l'intérêt d'une API, par conséquent, si les contrôles d'autorisation autour de ces objets sont interrompus, nous avons une vulnérabilité d'accès au niveau des objets cassés.



Exploiter la vulnérabilité d'accès au niveau des objets cassés

Il est généralement facile d’exploiter cette vulnérabilité une fois qu’elle a été découverte. Tout ce qu'un attaquant doit faire est de modifier un identifiant dans une requête et il a potentiellement accès à des objets auxquels il ne devrait pas être autorisé.


Voyons cela dans un exemple.

Ici, nous avons une URL qui est utilisée pour appeler une API:

https://myemail.com/messages/12345

Cet appel API est utilisé pour récupérer les messages privés d'un utilisateur. La ressource utilisée est messages .

Le message est l'objet auquel nous faisons référence dans l'autorisation au niveau de l'objet cassé. L'hypothèse est que les messages privés ne peuvent être lus que par le destinataire prévu.


Ensuite, nous avons l'identifiant du message 12345. C'est une partie importante pour un attaquant.

L'identifiant indique au service quel enregistrement renvoyer. L'API récupère cet enregistrement à partir d'un magasin de données et le renvoie dans la réponse.

Maintenant, que se passe-t-il si nous changeons l'identifiant de 12345 à 12346? par exemple:

https://myemail.com/messages/12346

Si le message avec id 12346 était destiné à notre utilisateur, nous devrions pouvoir le récupérer.


Mais si le message appartenait à un autre utilisateur, l'API ne devrait jamais le renvoyer. Si nous parvenons à récupérer le message, nous avons un échec d'autorisation d'objet de niveau cassé.

Un autre exemple est l'envoi d'une requête POST pour mettre à jour une ressource. Nous pouvons jouer avec l'id dans la charge utile JSON:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

Si nous devions mettre un potentiel userId dans la demande et avons pu mettre à jour les détails d'un autre utilisateur, alors nous avons un énorme problème.

Impact technique

Une fois que nous savons que la vulnérabilité existe, nous pouvons l'exploiter de toutes sortes de manières. Comme mentionné précédemment, nous pouvons utiliser diverses méthodes HTTP sur une API. Nous pouvons utiliser l'identifiant pour mettre à jour ou même supprimer des messages!

Que se passe-t-il si nous parvenons à parcourir tous les identifiants? Nous pourrions être en mesure de supprimer tous les messages stockés. C’est un grand impact.



Vulnérabilité commune

C'est une vulnérabilité très courante. Comme mentionné précédemment, les API sont utilisées pour accéder aux objets et dans la plupart des cas, nous utilisons des identifiants dans la demande pour identifier les ressources. La question est la suivante: y a-t-il des contrôles d'autorisation en place pour cet accès?

Il y a principalement deux raisons pour lesquelles nous finissons par avoir des vulnérabilités d'autorisation au niveau des objets cassés dans le code.

Le premier est qu’un contrôle de sécurité n’a tout simplement pas été mis en œuvre. Le code n'a pas été écrit pour effectuer des contrôles d'autorisation sur les demandes.

La deuxième raison est l'erreur humaine. Les gens font des fautes. Un bon exemple est dans une API qui gère à la fois les données sensibles sur les données non sensibles. Certaines demandes doivent être soumises à des contrôles d’autorisation et d’autres pas. Il peut donc être facile de rater un chèque lors de l'écriture du code.



Comment détecter

Les outils automatisés ne trouveraient normalement pas ce type de vulnérabilité car il a tendance à prendre au moins un peu de puissance cérébrale.

Il est relativement facile pour un humain de détecter cette vulnérabilité. Tout ce que nous devons faire est de trouver l’identifiant utilisé pour récupérer des objets.

Notez que l'identifiant peut être dans l'URL, dans le corps de la requête ou dans l'en-tête.

Nous devons également analyser et interpréter la réponse qui revient pour voir s'il y a une vulnérabilité ou non.

Outils

Nous pouvons utiliser n'importe quel outil qui inspecte les requêtes et réponses HTTP. Certains d'entre eux sont:

  • Outils de développement Google
  • Suite Burp
  • Facteur

Burp Suite peut également être utilisé pour automatiser certaines des requêtes.



Défense contre une autorisation de niveau objet cassé

Nous avons deux défenses ici.

La première défense consiste à utiliser ID imprévisibles tels que les GUID . Lorsque nous utilisons des nombres consécutifs dans le code, par exemple 12345, cela signifie que les identifiants sont très prévisibles. Un attaquant n'a pas besoin de beaucoup d'efforts pour parcourir les nombres afin de trouver des objets.

Un exemple de GUID:

d3b773e6-3b44-4f5f-9813-c39844719fc4

Les GUID sont complexes et très difficiles à deviner et ne sont pas séquentiels.

La prochaine défense est d'avoir du code pour vérifier l'autorisation . Ce contrôle n’a souvent pas lieu.

La vérification de l'autorisation doit avoir lieu chaque fois qu'un utilisateur présente l'API dans un identifiant qui va être utilisé. Le principe de base ici est que nous ne devons jamais faire confiance aux données que l'utilisateur donne à l'API.

L'ID demandé doit être vérifié pour confirmer que l'utilisateur est autorisé à accéder à l'objet.

Ces vérifications peuvent être de simples révisions de code pendant le développement du logiciel et / ou des vérifications automatisées qui vérifient les échecs d'autorisation tout au long du développement.



Conclusion

Comme nous l’avons vu, l’autorisation au niveau des objets cassés est une vulnérabilité courante et facile à repérer et à attaquer. Les impacts potentiels sont énormes.

La véritable source de cette vulnérabilité est la confiance dans les données transmises à l'API par le client.

Une grande partie de la défense consiste à nous assurer que nous ne faisons pas confiance à ces données. Nous devons donc nous assurer que les contrôles d'autorisation sont en place.