Pentest API

Quoi de mieux pour parler de Pentest d’API que d’évoquer le Top 10 OWASP API. 😄

Le Top 10 API de l’OWASP est un projet de sécurité des API qui se concentre sur les stratégies et les solutions pour comprendre et atténuer les vulnérabilités et les risques de sécurité uniques des API.
Grâce à des projets menés par la communauté à l’échelle mondiale, il s’agit d’une excellente source d’outils, de ressources, d’éducation et de formation pour les développeurs et les technologues afin de sécuriser les applications Web et mobiles.

Dans ce monde axé sur les applications, les API sont utilisées pour la communication par les microservices et les conteneurs, un peu comme les applications traditionnelles l’étaient pour l’internet à ses débuts.
La sécurité des API est l’un des principaux éléments de l’architecture de sécurité des microservices.

Je vais donc vous détailler ce Top 10 avec des exemples précis vous permettant de réutiliser ces différentes informations dans vos futurs pentests.

TOP 1 - Broken Object Level Authorisation

Voila notre champion le numéro 1 Broken Object Level Authorisation

Pour commencer qu’est ce qu’un objet :

• Il peut s’agir de n’importe quoi, allant d’un compte à une facture en passant par une note de crédit et tout ce qui se trouve entre les deux.

Comment reconnait-on un objet :

• Habituellement, ces objets sont marqués d’un identifiant car nous devons nous adresser directement à eux. C’est là que le problème peut se poser car nous devons toujours vérifier si l’utilisateur est autorisé à accéder à cet objet.

Cette vulnérabilité se produit lorsque le serveur ne vérifie pas correctement si l’utilisateur actuellement connecté ou si un utilisateur déconnecté peut lire, mettre à jour ou supprimer un objet pour lequel il n’a pas les droits.

Exemples :
Parfois, un ID utilisateur est transmis au serveur, ce qui peut arriver lorsque nous demandons toutes les informations concernant un certain utilisateur par exemple :

• https://website.com/get_users_informations?userID=1234

Si nous remplaçons l’ID utilisateur par l’ID utilisateur de quelqu’un d’autre, nous ne devrions pas être en mesure d’obtenir les informations concernant les autres utilisateurs, mais lorsqu’un problème Broken Object Level Authorisation se pose, nous pouvons voir les informations concernant les autres utilisateurs.

Ce type de vulnérabilité peut également exister parce que des identifiants d’objets sont transmis au serveur lorsque celui-ci ne vérifie pas correctement si l’utilisateur est autorisé à utiliser cet objet. Cela peut se produire très facilement, par exemple lorsqu’un développeur doit sécuriser certaines ressources et d’autres non. Il peut oublier de sécuriser l’un des objets qui devrait l’être.

TOP 2 - Broken User Authentication

Cette vulnérabilité se concentre sur le système d’authentification.
Voici une petite checklist pour vérifier si l’API est vulnérable.
Lorsque l’une des conditions suivantes est vraie, on peut parler de “Broken User Authentication”.

• Credential Stuffing possible
• Absence de Captcha quand cela est nécessaire
• Mauvaise politique de mot de passe
• Présence de paramètres sensibles dans l’URL (mots de passe, cookies)
• Accepte un token JWT non signé
• Endpoint qui ne chiffre pas le mot de passe ou utilisation d’un algorithme faible

TOP 3 - Excessive Data Exposure

Une API n’est censée renvoyer que les données requises aux utilisateurs finaux, mais il arrive que les équipes commettent une erreur ou choisissent la voie de la facilité et mettent en œuvre des API qui renvoient toutes les données au client. Lorsque ces API renvoient trop de données, on peut parler d’exposition excessive des données.

Exemple :
Un système de surveillance basé sur l’IOT permet aux administrateurs de créer des utilisateurs avec différentes autorisations. Un administrateur a créé un compte utilisateur pour un nouvel agent de sécurité qui ne doit avoir accès qu’à des bâtiments spécifiques du site.
Dès que l’agent de sécurité utilise son application mobile, un appel API est déclenché vers : /api/sites/111/cameras afin de recevoir des informations sur les caméras disponibles et de les afficher sur le tableau de bord.
La réponse contient une liste avec des détails sur les caméras dans le format suivant : {“id” : “xxx”, “live_access_token” : “xxxx-bbbbb”, “building_id” : “yyy”}.
Alors que l’interface graphique du client n’affiche que les caméras auxquelles l’agent de sécurité doit avoir accès, la réponse API réelle contient une liste complète de toutes les caméras du site.

TOP 4 - Lack of Resources and Rate Limiting

Pour commencer il faut comprendre que chaque fois qu’une API reçoit une requête, l’API doit répondre.
Pour générer cette réponse, l’API a besoin de ressources (CPU, RAM, réseau et parfois même espace disque), mais la quantité requise dépend fortement de la tâche à accomplir.

Plus le traitement logique est important ou plus les données sont renvoyées, plus les ressources sont utilisées par un seul appel et cela peut s’accumuler rapidement.

Ce problème est aggravé par le fait que la plupart des API résident sur des hôtes partagés, ce qui signifie qu’elles se battent toutes pour les mêmes ressources, ce qui peut signifier que l’attaquant désactive une API secondaire non liée en consommant toutes les ressources.