La catégorie « Broken Object Property Level Authorization » (autorisation défaillante au niveau des propriétés d'objet) regroupe les attaques qui surviennent en obtenant un accès non autorisé à des informations sensibles via l'exposition excessive de données (précédemment classée numéro 3 dans le Top 10 de la sécurité API OWASP 2019) ou l'assignation de masse (précédemment en sixième position).
Ces deux techniques reposent sur la manipulation des points de terminaison (endpoints) de l'API pour accéder à des données sensibles.
Cette nouvelle catégorie traite de l'autorisation au niveau des propriétés d'objet, par opposition à l'autorisation au niveau de l'objet (numéro 1 sur la liste depuis 2019).
La raison principale de l'introduction de cette nouvelle menace sur la liste est que, même si une API peut appliquer des mesures de sécurité suffisantes au niveau de l'objet, cela peut ne pas suffire à la protéger. Une autorisation plus spécifique couvrant les objets et leurs caractéristiques est souvent nécessaire. Les différents niveaux d'accès au sein d'un objet API doivent également être pris en compte, car un objet API possède souvent à la fois des propriétés publiques et privées.
Impact potentiel d'une autorisation défaillante au niveau des propriétés d'objet
Les API envoient souvent plus d'informations que nécessaire dans une réponse API, laissant à l'application cliente le soin de filtrer les données et de générer une vue pour l'utilisateur. Un attaquant peut intercepter le trafic envoyé au client pour accéder à des données potentiellement sensibles, notamment des numéros de compte, des adresses e-mail, des numéros de téléphone et des jetons d'accès.
De plus, un attaquant exploitant ce type de vulnérabilité peut mettre à jour des propriétés d'objet auxquelles il ne devrait pas avoir accès, ce qui lui permet d'élever ses privilèges, de falsifier des données et de contourner les mécanismes de sécurité.
À quoi ressemble une attaque par autorisation défaillante au niveau des propriétés d'objet ?
Dans l'exemple ci-dessus, le code côté client s'exécutant dans le navigateur Web de l'utilisateur soumet une requête POST à une API backend pour récupérer des informations de paiement stockées. Dans ce cas, l'API récupère des informations de carte de crédit stockées, plus précisément le numéro de compte principal (PAN) et le code de vérification de la carte (CVV). Dans le monde du traitement des paiements et de la gestion des cartes de crédit, ce type de données est considéré comme sensible dans le cadre de la norme PCI-DSS et doit être protégé de manière appropriée. L'étendue des mesures de protection nécessaires varie en fonction de l'exposition de l'environnement des données du titulaire de carte, ou de l'endroit où les données sont stockées, traitées ou transmises.
Ce partage de données sensibles peut être intentionnel dans le cadre de la conception ou nécessaire au fonctionnement. Par conséquent, les organisations renforcent la sécurité avec des contrôles supplémentaires tels qu'une authentification plus forte ou un transport chiffré pour garantir que les données sont suffisamment protégées. Dans l'exemple, vous pouvez voir des en-têtes de sécurité HTTP supplémentaires pour aider à protéger les données, tels que « x-frame-options » pour atténuer les attaques par cross-frame scripting et « x-xss-protection » pour atténuer les attaques par cross-site scripting. Certaines organisations peuvent également masquer les données renvoyées à un client pour éviter les cas où quelqu'un intercepterait le trafic ou consulterait des données en dehors de l'application cliente prévue. Se fier au code côté client pour filtrer ou masquer ces données sensibles n'est généralement pas approprié, car les attaquants contournent régulièrement le code des applications Web et mobiles côté client pour appeler directement les API.
Dans le deuxième exemple ci-dessus, l'attaquant a modifié l'appel API pour mettre à jour son compte, élever son rôle et ses privilèges vers un rôle « admin », et contourner l'authentification unique (SSO). Si l'opération réussit, l'attaquant peut alors effectuer des actions au sein de l'application en tant qu'administrateur.
Exemple concret : les données des utilisateurs de Twitter compromises
Selon un déclaration publiée par Twitter en août 2022, une vulnérabilité d'autorisation au niveau des propriétés d'objet a été initialement détectée par leur programme de bug bounty en janvier 2022. En raison de cette faille, si quelqu'un soumettait une adresse e-mail ou un numéro de téléphone aux systèmes de Twitter, il était informé du compte Twitter associé à ces informations, le cas échéant. Le problème a été étudié et corrigé par Twitter à l'époque, sans aucune preuve suggérant qu'il ait été exploité dans la nature. Cependant, en juillet 2022, il est apparu qu'un acteur malveillant avait tiré parti de cette faille avant qu'elle ne soit corrigée par l'entreprise et proposait désormais de vendre les données compilées.
Cet incident très médiatisé a mis en lumière le risque que ce type de vulnérabilité de sécurité peut poser, même pour une marque bien établie disposant de vastes ressources et de programmes de sécurité supposés robustes.
Pourquoi les outils existants ne parviennent pas à vous protéger contre les vulnérabilités d'autorisation au niveau des propriétés d'objet
Les contrôles de sécurité traditionnels comme les WAF et les passerelles API n'ont aucune visibilité sur l'activité des API et la logique métier ; ils ne parviennent donc pas à identifier les données sensibles transmises via une API ni à comprendre le risque d'exposition associé. Ils ne peuvent pas non plus savoir si l'appelant de l'API dans l'exemple ci-dessus devrait être autorisé à envoyer une requête utilisant la méthode PUT avec des paramètres supplémentaires, ne faisant aucune distinction entre un appel légitime et une activité malveillante. Pour ces contrôles traditionnels, cet appel API semble normal. Au mieux, un WAF ou une passerelle API peut offrir des mécanismes de filtrage de messages basiques pour bloquer ce type de requête en bloc. Cependant, des paramètres supplémentaires peuvent être nécessaires pour d'autres utilisateurs et d'autres cas d'usage. Cela nécessiterait également une connaissance détaillée et préalable de la conception et de l'utilisation prévue de l'API par les équipes de développement, afin que les équipes opérationnelles puissent mettre en œuvre ne serait-ce que des filtres de messages basiques.
Généralement, les passerelles API et les WAF utilisent une correspondance de modèles et un filtrage de messages basiques pour identifier les types de données sensibles, également appelés modèles d'expressions régulières (regex). Bien que ces types de filtres puissent détecter des données sensibles bien définies telles que les numéros de carte bancaire (PAN) ou les numéros de sécurité sociale, ils ne comprennent pas le contexte de l'API ni les flux de logique métier. Ils signaleront toute donnée correspondant au modèle, sans se soucier de savoir s'il est nécessaire de bloquer la requête, de chiffrer les charges utiles ou d'occulter les données. Les passerelles API sont souvent utilisées pour servir d'intermédiaires aux appels API contenant des données sensibles, ce qui peut être nécessaire dans le cadre d'une architecture d'entreprise, d'une conception d'application ou d'une intégration système globale. Bloquer ou masquer les données sensibles de manière systématique compromet souvent les fonctionnalités, ce qui rend les équipes de sécurité réticentes à utiliser ces capacités de manière intensive dans les proxys, préférant s'en remettre à la couche API/application pour contrôler l'exposition.
Comment protéger vos API contre les vulnérabilités d'autorisation au niveau des propriétés d'objet
Une solution de sécurité des API doit être capable d'identifier et de signaler la grande variété de types de données sensibles pouvant être envoyées dans les requêtes et réponses API, ainsi que toute activité anormale où des attaquants envoient des requêtes API manipulées avec des paramètres non autorisés.
Ces solutions doivent également être capables d'établir une base de référence et de suivre l'accès aux API par point de terminaison et par utilisateur afin d'identifier une consommation excessive de données sensibles et de repérer les cas où des paramètres supplémentaires sont transmis dans des appels API sortant du comportement habituel. Les solutions de sécurité des API doivent également être en mesure d'identifier les attaquants lorsqu'ils sondent l'API pendant leur phase de reconnaissance pour comprendre la structure et la logique métier de l'API.
Pour en savoir plus sur la façon dont Salt peut aider à protéger votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.