OWASP API Security Top 10
OWASP, la référence incontestée du secteur en matière de sécurité des applications, a présenté fin septembre 2019 à Amsterdam un nouveau Top 10 des vulnérabilités dans le développement des API (Release candidate).
Comme pour les Top 10 des failles pour les applications Web et mobiles, cette nouvelle liste permet d’améliorer la sécurité des API, utilisées dans la quasi-totalité des architectures applicatives désormais.
L’objectif de ce Top 10 est d’informer sur les risques liés à ces failles, tels que la divulgation de la logique applicative ou le vol d’informations personnelles identifiables (PII), en les classant et les rendant compréhensibles, mais surtout en fournissant des conseils sur la manière d’y remédier et ainsi prévenir de leurs exploitations par des personnes mal intentionnées.
Voyons de plus près ces différentes vulnérabilités :
Contenu
1) Broken Object Level Authorization
Cette faille concerne les accès illicites aux objets en contournant les mécanismes d’autorisation et de contrôle d’accès qui ne vérifieraient pas correctement le droit d’accès du demandeur à un objet avant toute action.
L’exploitation standard de ce type de vulnérabilité est la possibilité de manipuler un identifiant et ainsi de pouvoir énumérer toutes les instances de l’objet.
2) Broken Authentication
Le mécanisme d’authentification est toujours essentiel pour les API. Il doit donc être aussi standard que possible pour éviter tout problème à ce niveau.
Par exemple, une mauvaise configuration peut facilement conduire à une attaque de credential stuffing ou à un brute-force de token ou encore à la détection de clés de chiffrement faibles.
3) Excessive Data Exposure
Les réponses aux appels doivent être adaptées à leur objectif initial et ne doivent pas contenir plus de données que prévu, en particulier dans le cas de manipulation de données sensibles (PII). Par exemple, lorsque l’on s’appuie uniquement sur le côté client pour filtrer les données avant de les afficher, un attaquant pourrait accéder à toutes les données en interceptant les réponses avant ce filtrage.
4) Lack of Resources & Rate Limiting
Une API est supposée être définie pour un certain usage dans un contexte délimité. Le risque pour une API dont l’usage et/ou le contexte sont mal définis est la possibilité de saturer temporairement le service et, pire, de créer un déni de service si aucune protection n’a été mise en place.
5) Broken Function Level Authorization
Comme pour les applications Web, les contrôles d’autorisation doivent être appliqués partout pour éviter tout accès non autorisé à une ressource ou à une fonction.
Le déni par défaut (principe de « least privilege ») est la bonne pratique à utiliser pour n’oublier aucun point d’accès.
6) Mass Assignment
Les API peuvent légitimement proposer une fonctionnalité de modification des attributs d’un objet, mais toutes les entrées doivent être contrôlées car certaines ne doivent pas être mises à jour par les objets entrants en provenance du client.
Le risque encouru avec ce type de vulnérabilité est par exemple la modification de l’autorisation porté dans un attribut de l’objet pour obtenir le rôle d’administrateur.
7) Security Misconfiguration
Il s’agit là d’éviter toutes les potentielles configurations par défaut, suffisamment pzu sûres pour une utilisation en production, voire des configurations jugées inutiles, trop permissives, ou même des messages d’erreur trop détaillés, qui révèlent des informations sensibles pouvant ensuite être exploitées.
8) Injection
Cela concerne la possibilité de faire interpréter des données non fiables pour faire exécuter une requête ou une commande côté serveur.
La règle de base pour se protéger est de ne jamais faire confiance aux entrées utilisateur et de toujours valider les données reçues avant d’exécuter une commande ou une requête.
9) Improper Assets Management
La gestion du cycle de vie des APIs peut conduire à laisser des points de terminaison (endpoints) actifs obsolètes pour des raisons commerciales et donc l’inventaire est donc important pour éviter tout risque, ou a minima pouvoir l’identifier et le surveiller.
Les endpoints obsolètes ou de débogage sont généralement la cible privilégiée des attaquants.
10) Insufficient Logging & Monitoring
De la même manière que pour les applications standards, la capacité de détection de toute violation / attaque est de plus en plus importante. Il est nécessaire de se doter d’outils de monitoring et d’avoir des logs détaillées afin d’une part d’être en mesure de répondre rapidement à un incident ou une attaque et donc éviter la propagation, mais aussi de se doter d’un historique de traces qui seront dans certains cas très utiles pour des aspects juridiques.
En conclusion, ce nouvel outil de sécurité permettra d’aider les entreprises à adapter leurs politiques de sécurité des applications avec une qualification des vulnérabilités dédiée aux APIs et ainsi réduire les risques Cyber inhérents.
Source : https://www.owasp.org/index.php/OWASP_API_Security_Project
