Série OWASP Top 10 API : Maîtriser la sécurité pour les développeurs - Exposition excessive de données

La vulnérabilité d'exposition excessive de données se distingue des autres problèmes d'API listés par l'OWASP, car elle concerne un type de données très spécifique. Les mécanismes réels derrière cette vulnérabilité sont similaires à d'autres, mais l'exposition excessive de données, dans ce cas précis, se définit par l'implication de données légalement protégées ou hautement sensibles. Cela peut inclure toute information personnellement identifiable, souvent appelée PII. Il peut également s'agir d'informations relatives à l'industrie des cartes de paiement, ou PCI. Enfin, l'exposition excessive de données peut inclure toute information soumise à des lois sur la protection de la vie privée, telles que le Règlement général sur la protection des données (RGPD) en Europe ou la loi HIPAA (Health Insurance Portability and Accountability Act) aux États-Unis.

Comme vous pouvez l'imaginer, c'est une source de vive inquiétude, et il est impératif que les développeurs avertis apprennent à éliminer ces failles dès que possible. Si vous êtes prêt à affronter le dragon de l'exposition de données, lancez-vous dans notre défi ludique :

Quel a été votre score ? Poursuivez votre lecture pour en savoir plus :

Quels sont quelques exemples d'exposition excessive de données ?

L'une des principales raisons pour lesquelles l'exposition excessive de données se produit est que les développeurs et les codeurs n'ont pas une visibilité suffisante sur le type de données que leurs applications vont utiliser. Pour cette raison, les développeurs ont tendance à utiliser des processus génériques où toutes les propriétés des objets sont exposées aux utilisateurs finaux.

Les développeurs supposent aussi parfois que les composants frontend effectueront un filtrage des données avant d'afficher toute information aux utilisateurs. Pour la plupart des données génériques, ce n'est rarement un problème. Mais exposer des données légalement protégées ou sensibles aux utilisateurs dans le cadre d'un ID de session, par exemple, peut entraîner de graves problèmes, tant sur le plan de la sécurité que sur le plan juridique.

Pour illustrer la facilité avec laquelle des données sensibles peuvent être partagées accidentellement, le rapport OWASP imagine un scénario où un agent de sécurité reçoit l'accès à des caméras IoT spécifiques dans un établissement. Peut-être que ces caméras surveillent des zones scellées et sécurisées, tandis que d'autres caméras filmant des personnes devraient être réservées aux agents ou aux superviseurs disposant d'autorisations plus élevées.

Pour donner à l'agent l'accès aux caméras autorisées, les développeurs peuvent utiliser un appel API comme celui-ci.

/api/sites/111/cameras

En réponse, l'application enverrait des détails sur les caméras que l'agent est autorisé à voir sous le format suivant :

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

En apparence, cela semble fonctionner parfaitement. L'agent, qui utilise l'interface utilisateur graphique de l'application, ne verrait que les flux des caméras qu'il est autorisé à consulter. Le problème est qu'en raison du code générique utilisé, la réponse réelle de l'API contiendrait une liste complète de toutes les caméras de l'établissement. Quiconque espionnant le réseau et capturant ces données, ou compromettant le compte de l'agent, serait en mesure de découvrir les emplacements et la nomenclature de chaque caméra sur le réseau. Ils pourraient alors accéder à ces données sans aucune restriction.

Éliminer l'exposition excessive de données

La clé principale pour prévenir l'exposition excessive de données est de comprendre les données et les protections qui les entourent. Créer des API génériques et laisser au client le soin de trier les données avant de les afficher aux utilisateurs est un choix dangereux qui mène à de nombreuses failles de sécurité évitables.

En plus de comprendre les protections de données pertinentes, il est également important de mettre fin au processus consistant à tout envoyer à un utilisateur via des API génériques. Par exemple, le code tel que to_json() et to_string() doit être évité. Au lieu de cela, le code devrait sélectionner spécifiquement les propriétés qui doivent être renvoyées aux utilisateurs autorisés et n'envoyer que ces informations.

Afin de garantir qu'aucune donnée protégée n'est accidentellement partagée en excès, les organisations devraient envisager de mettre en œuvre un mécanisme de validation de réponse basé sur un schéma comme couche de sécurité supplémentaire. Il devrait définir et appliquer les données renvoyées par toutes les méthodes API, y compris les règles de rapport d'erreurs.

Enfin, toutes les données classées comme contenant des PII ou des PCI, ou les informations protégées par des réglementations telles que le RGPD ou la loi HIPAA, doivent être protégées par un chiffrement robuste. Ainsi, même si l'emplacement de ces données est révélé dans le cadre d'une vulnérabilité d'exposition excessive, il existe une bonne ligne de défense secondaire en place qui devrait protéger les données, même si elles tombent entre les mains d'un utilisateur malveillant ou d'un acteur malveillant.

Consultez les pages du blog Secure Code Warrior pour plus d'informations sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour garder toutes vos compétences en cybersécurité affûtées et à jour.