Risques d’exposition des métadonnées

L’équipe de sécurité d’un fournisseur de recherche clinique était fière de ses contrôles de protection des données : données d’essais cliniques des patients chiffrées au repos et en transit, contrôles d’accès étroitement gérés, journalisation d’audit complète. Un chercheur en sécurité réalisant un test d’intrusion autorisé a découvert une importante vulnérabilité de divulgation d’informations sans aucun rapport avec les données protégées elles-mêmes : les réponses de l’API du fournisseur contenaient des en-têtes HTTP détaillés qui révélaient la version du moteur de base de données, le framework ORM utilisé, le système d’exploitation du serveur et l’architecture des services internes. Son stockage de fichiers accessible au public contenait des documents de protocole d’essais cliniques dont les métadonnées (noms des auteurs, organisation, classification interne des documents et historique des versions) révélaient l’identité du promoteur de l’essai et des détails du protocole qui n’avaient pas été rendus publics. Les messages d’erreur renvoyés par l’application comprenaient les noms complets des tables de la base de données, la structure des colonnes et, dans certains cas, les paramètres des requêtes. Les données des essais cliniques étaient bien protégées. Les métadonnées qui les entouraient révélaient le promoteur de l’essai, la structure du protocole, l’infrastructure technique et suffisamment de détails sur la surface d’attaque pour réduire considérablement l’effort nécessaire à l’exploitation de toute vulnérabilité présente dans l’environnement.

Qu’est-ce vraiment que le problème du risque d’exposition des métadonnées ?

Les métadonnées sont des données sur les données : les informations contextuelles, structurelles et techniques qui décrivent, situent et accompagnent les données principales sans être elles-mêmes les données principales. Dans le contexte de la sécurité de l’information, les métadonnées englobent les en-têtes de réponse HTTP qui décrivent les caractéristiques du serveur et de l’application, les propriétés des documents qui enregistrent l’auteur et l’origine organisationnelle, les métadonnées du système de fichiers qui enregistrent l’historique des accès et le contexte de création, les structures de réponse des API qui révèlent les schémas de bases de données et les architectures de services, les messages d’erreur qui exposent la structure des requêtes et le fonctionnement interne du système, ainsi que toute la gamme d’informations contextuelles que les applications et les systèmes génèrent en même temps que leurs données principales.

L’importance des métadonnées pour la sécurité découle de leur densité d’information au regard de leur faible priorité de gouvernance. Les métadonnées contiennent souvent des informations plus précieuses sur le plan opérationnel pour un attaquant que les données principales elles-mêmes, non que les données principales soient sans importance, mais parce que les métadonnées fournissent souvent les renseignements de reconnaissance qui rendent possible l’attaque contre les données principales. Une version de moteur de base de données divulguée dans un en-tête HTTP indique à un attaquant quelles CVE rechercher. Une version de framework dans un message d’erreur lui indique quelles vulnérabilités d’injection et de désérialisation tester. Une classification interne de document dans une propriété de fichier révèle ce que l’organisation considère comme sensible et quels documents cibler en priorité dans un scénario d’exfiltration. Aucune de ces informations ne constitue les données principales que les programmes de sécurité sont conçus pour protéger, mais elles permettent d’y accéder plus efficacement.

La dimension des métadonnées relative à la vie privée est tout aussi importante et de plus en plus reconnue dans les lignes directrices réglementaires. Le moment et la fréquence des visites d’un patient sur un portail de santé révèlent des schémas de comportement susceptibles de révéler des problèmes de santé sans exposer de dossiers cliniques précis. Les métadonnées des communications chiffrées (qui a communiqué avec qui, quand, à quelle fréquence et pendant combien de temps) peuvent révéler des schémas relationnels, des structures organisationnelles et des informations comportementales que le chiffrement du contenu était censé protéger. Les horodatages d’accès aux fichiers, les données de localisation intégrées aux photographies et les identifiants d’appareils dans les journaux applicatifs sont autant de catégories de métadonnées qui ont des incidences sur la vie privée indépendamment des données qu’elles décrivent.

Les risques d’exposition des métadonnées se concentrent autour de cinq catégories d’exposition précises dans les environnements des fournisseurs :

Divulgation par les en-têtes de réponse HTTP : métadonnées du serveur et de l’application renvoyées dans les en-têtes de réponse HTTP, qui révèlent le moteur de base de données, le framework, le système d’exploitation et l’architecture des services internes à quiconque inspecte les réponses
Métadonnées des documents et des fichiers : identité de l’auteur, organisation, classification interne et historique des versions intégrés aux propriétés des documents et diffusés avec leur contenu
Messages d’erreur verbeux : réponses d’erreur des applications qui incluent la structure des requêtes en base de données, les noms de tables, les traces d’appels et des détails internes du système visibles par les utilisateurs qui déclenchent des erreurs
Divulgation par la structure des réponses des API : réponses des API qui révèlent le schéma de la base de données, la structure des relations et les modèles objets internes à travers la cohérence du nommage des champs et des schémas de réponse
Exposition des métadonnées des journaux : journaux applicatifs contenant des informations contextuelles sensibles (identifiants d’utilisateurs, jetons de session, paramètres de requêtes et détails du routage interne) exposées par des erreurs de configuration de l’infrastructure de journalisation

Pourquoi c’est important

L’exposition des métadonnées compte pour la TPRM, car elle représente une catégorie de divulgation d’informations largement invisible pour les évaluations axées sur la protection des données principales. Une évaluation qui confirme le chiffrement des données, les contrôles d’accès et la journalisation d’audit couvre les contrôles de protection des données principales. Elle n’évalue généralement pas si les en-têtes HTTP révèlent l’infrastructure technique, si les propriétés des documents révèlent la classification interne ou si les messages d’erreur exposent la structure de la base de données. Les métadonnées qu’un attaquant utilise pour planifier une attaque contre l’environnement du fournisseur sont précisément celles que l’évaluation de sécurité du fournisseur n’a peut-être jamais examinées.

La dimension de la reconnaissance technique est le risque le plus directement utile à un attaquant. Un attaquant qui identifie la pile technologique d’un fournisseur cible par l’inspection des en-têtes HTTP, l’analyse des messages d’erreur et l’examen de la structure des réponses des API a considérablement réduit son effort de développement d’attaque. Au lieu de tester à l’aveugle un environnement inconnu, il peut rechercher les CVE connues pour les versions précises divulguées, élaborer des méthodes d’exploitation adaptées aux versions de framework identifiées et cibler en priorité les vulnérabilités les plus susceptibles d’être exploitables compte tenu de l’architecture révélée. Les contrôles des données principales restent en place. L’attaque est devenue plus efficace grâce aux métadonnées.

Pour les praticiens de la TPRM, l’évaluation de l’exposition des métadonnées ajoute une dimension que peu d’évaluations standard couvrent : il s’agit de demander non seulement si les données sont protégées, mais aussi si les informations qui entourent les données dans l’environnement du fournisseur sont correctement contrôlées. C’est particulièrement pertinent pour les fournisseurs qui exposent des API externes, distribuent des documents à leurs clients et exploitent des interfaces web dont les en-têtes HTTP et les messages d’erreur sont visibles par quiconque dispose d’un navigateur et des outils de développement.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à traiter la gouvernance des métadonnées comme une considération secondaire par rapport à la protection des données principales. Des organisations qui investissent fortement dans le chiffrement des données, le contrôle de l’accès aux données et la surveillance de cet accès peuvent n’avoir jamais examiné ce que leurs systèmes révèlent sur eux-mêmes à travers les métadonnées qui entourent les données. Les en-têtes HTTP sont visibles par n’importe quel navigateur. Les propriétés des documents sont accessibles à tout utilisateur qui ouvre un fichier. Les messages d’erreur sont visibles par tout utilisateur qui déclenche une erreur. Ce sont ces divulgations d’informations que les programmes standard de protection des données négligent.

Le deuxième échec consiste à ne pas inclure la divulgation de métadonnées dans le périmètre des tests d’intrusion. Un test d’intrusion qui évalue les contrôles d’accès, les vulnérabilités d’injection et les mécanismes d’authentification peut ne pas examiner spécifiquement les informations divulguées par les en-têtes HTTP, les messages d’erreur et les métadonnées des documents. La divulgation de métadonnées est un risque qui facilite la reconnaissance plutôt qu’un risque d’exploitation directe, et les objectifs de test axés sur la reconnaissance doivent être explicitement inclus dans le périmètre du test.

Traiter la gouvernance des métadonnées comme secondaire par rapport à la protection des données principales : les métadonnées contiennent souvent des renseignements plus utiles sur le plan opérationnel pour un attaquant que les données protégées
En-têtes HTTP non évalués : divulgation des versions du serveur et du framework non incluse dans le périmètre de l’évaluation de sécurité
Métadonnées des documents non gouvernées : identité de l’auteur et classification interne dans les propriétés des documents non supprimées avant leur diffusion
Messages d’erreur non évalués : réponses d’erreur verbeuses non incluses dans le périmètre des tests de sécurité
Divulgation de métadonnées absente du périmètre des tests d’intrusion : la collecte de renseignements de reconnaissance par les métadonnées n’est pas un objectif de test défini

À quoi ressemblent les bonnes pratiques

Les programmes matures de gouvernance des métadonnées traitent la divulgation d’informations par les métadonnées avec la même rigueur que la divulgation d’informations par les données : ils suppriment ou masquent les en-têtes HTTP identifiant le serveur, mettent en place des messages d’erreur génériques qui n’exposent pas le fonctionnement interne du système, suppriment les métadonnées des documents avant leur diffusion et incluent l’évaluation de la divulgation de métadonnées dans les programmes de tests de sécurité.

Durcissement des en-têtes HTTP : version du serveur, version du framework et identifiants de la pile technologique supprimés des en-têtes de réponse HTTP
Gestion générique des erreurs : erreurs applicatives renvoyées aux utilisateurs sous forme de messages génériques, sans structure de base de données, détail des requêtes ni traces d’appels
Suppression des métadonnées des documents : auteur, organisation, classification interne et historique des versions supprimés des documents avant leur diffusion externe
Minimisation de la structure des réponses des API : réponses des API conçues pour divulguer le minimum d’informations nécessaires plutôt que des modèles objets complets
Divulgation de métadonnées dans le périmètre des tests d’intrusion : inspection des en-têtes HTTP, analyse des messages d’erreur et évaluation des métadonnées des documents comme objectifs de test définis

Outils

Gouverner l’exposition des métadonnées exige à la fois les contrôles techniques permettant de supprimer ou de masquer les métadonnées identifiantes et les outils de test permettant d’évaluer ce qui est actuellement divulgué.

En-têtes de sécurité HTTP : OWASP Secure Headers Project, SecurityHeaders.com

Le OWASP Secure Headers Project fournit des recommandations sur les en-têtes HTTP à supprimer ou à durcir pour empêcher l’identification du serveur et la divulgation d’informations. SecurityHeaders.com propose une évaluation gratuite de la configuration des en-têtes HTTP de tout site web accessible au public. Pour les praticiens de la TPRM, lancer une analyse SecurityHeaders.com sur les applications d’un fournisseur exposées à l’extérieur fournit une évaluation immédiate, sans accès nécessaire, de la divulgation d’informations par les en-têtes HTTP, des informations visibles par tout client HTTP sans aucune authentification.

Gestion des métadonnées des documents : Microsoft Purview, outils de métadonnées d’Adobe Acrobat

Les outils de suppression des métadonnées des documents suppriment ou masquent l’auteur, l’organisation, la classification interne et l’historique des versions des documents avant leur diffusion. Les applications Microsoft Office offrent des fonctions intégrées d’inspection et de suppression des métadonnées. La fonction d’assainissement d’Adobe Acrobat supprime les métadonnées et le contenu masqué des PDF. Pour les praticiens de la TPRM, demander si le fournisseur supprime les métadonnées des documents distribués aux clients ou à des tiers constitue une question précise sur la gouvernance des métadonnées des documents.

Tests de sécurité des API : 42Crunch, Burp Suite, OWASP ZAP

Les outils de test de sécurité des API évaluent la divulgation d’informations dans les réponses des API, en vérifiant si ces réponses révèlent le schéma de la base de données, les modèles objets internes ou des détails de mise en œuvre à travers la cohérence du nommage des champs et de la structure des réponses. Pour les praticiens de la TPRM, demander si les tests de sécurité des API comprennent une évaluation de la divulgation d’informations par l’analyse de la structure des réponses et des en-têtes constitue la question précise sur les objectifs de test tenant compte des métadonnées.

Enjeux de gouvernance

La difficulté de gouvernance des métadonnées tient à leur omniprésence. Les métadonnées sont générées par chaque système, application et document d’un environnement comme effet secondaire du fonctionnement normal : elles ne sont pas créées intentionnellement comme un risque de divulgation, mais s’accumulent en continu au fil des activités courantes. Les supprimer exige de configurer délibérément chaque système qui les génère : serveurs HTTP configurés pour masquer les en-têtes de version, gestionnaires d’erreurs applicatives configurés pour renvoyer des messages génériques, outils de création de documents configurés pour supprimer les métadonnées, frameworks d’API configurés pour réduire la verbosité des réponses. Ces configurations doivent être appliquées et maintenues dans un environnement hétérogène de systèmes et d’applications.

Pour les programmes de TPRM, l’approche de gouvernance pragmatique consiste à inclure l’évaluation de la divulgation de métadonnées dans les exigences de tests de sécurité des fournisseurs, en demandant précisément si les en-têtes HTTP, les messages d’erreur et les métadonnées des documents sont évalués dans le cadre du programme de tests de sécurité du fournisseur. Des outils gratuits comme SecurityHeaders.com permettent également aux praticiens de la TPRM de réaliser une évaluation rapide, sans accès, de la configuration des en-têtes HTTP exposés à l’extérieur par un fournisseur, avant ou en parallèle de toute évaluation formelle.

Lancer SecurityHeaders.com sur les URL externes du fournisseur : évaluation gratuite, immédiate et sans accès de la divulgation par les en-têtes HTTP
Demander si la divulgation de métadonnées fait partie du périmètre des tests d’intrusion : en-têtes HTTP, messages d’erreur et métadonnées des documents comme objectifs de test définis
Poser des questions sur la gestion des métadonnées des documents : les métadonnées des documents distribués aux clients sont-elles supprimées ?
Poser des questions sur la verbosité des messages d’erreur : les erreurs applicatives renvoient-elles des messages génériques ou des détails qui exposent le système ?
Inclure la divulgation de métadonnées dans l’évaluation de sécurité des fournisseurs comme dimension standard, au même titre que la protection des données principales

Si vous êtes une petite équipe

Lancez SecurityHeaders.com sur l’URL principale exposée à l’extérieur du fournisseur avant votre prochaine réunion d’évaluation. L’analyse prend trente secondes et révèle la configuration des en-têtes HTTP, en particulier les en-têtes identifiant le serveur et le framework présents dans la réponse. Cette information vous indique immédiatement si le fournisseur a traité la divulgation de métadonnées HTTP ou si son API externe et son application web diffusent leur pile technologique à quiconque lance la même analyse. Demandez ensuite si la gestion des métadonnées des documents et la verbosité des messages d’erreur font partie du périmètre de ses tests d’intrusion. Trois questions, une analyse gratuite, un signal immédiat et significatif.

Lancer SecurityHeaders.com sur les principales URL externes du fournisseur avant l’évaluation
Demander si les métadonnées des documents sont supprimées avant leur diffusion externe
Demander si les messages d’erreur renvoient des réponses génériques ou des détails qui exposent le système
Demander si la divulgation de métadonnées est incluse dans le périmètre des tests d’intrusion

Ce qu’il faut exiger

Demandez directement :

« Avez-vous évalué les informations divulguées par les en-têtes de réponse HTTP de vos applications exposées à l’extérieur ? En particulier, les en-têtes de votre serveur et de vos applications révèlent-ils le moteur de base de données, la version du framework ou le système d’exploitation du serveur à tout client HTTP ? »

« Les messages d’erreur de vos applications renvoient-ils aux utilisateurs des réponses d’erreur génériques, ou incluent-ils la structure de la base de données, le détail des requêtes ou des traces d’appels qui exposent le fonctionnement interne du système ? »

« Supprimez-vous les métadonnées (auteur, organisation, classification interne et historique des versions) des documents distribués aux clients, et la gestion des métadonnées des documents fait-elle partie de votre programme de sécurité de l’information ? »

Preuves attendues

Revue de la configuration des en-têtes HTTP : en-têtes identifiant le serveur supprimés
Configuration de la gestion des erreurs : messages d’erreur génériques sans détails sur le système
Processus de gestion des métadonnées des documents : suppression avant toute diffusion externe
Inclusion de la divulgation de métadonnées dans le périmètre des tests d’intrusion

Lancez SecurityHeaders.com sur l’URL principale du fournisseur en même temps que vous posez ces questions. Le résultat de l’analyse fournit une preuve indépendante de la configuration des en-têtes HTTP qu’aucune réponse à un questionnaire ne peut remplacer. Un fournisseur dont les en-têtes révèlent la version du serveur et le framework dans le résultat de l’analyse a répondu à la première question avec une preuve plus fiable que n’importe quelle auto-déclaration.

Comment le prouver

L’exposition des métadonnées est traitée dans le guide de test de l’OWASP relatif à la divulgation d’informations, dans la CWE-200 (exposition d’informations sensibles à un acteur non autorisé) et dans les recommandations générales de configuration sécurisée du NIST SP 800-53. Démontrer la diligence requise exige de prouver que la divulgation de métadonnées a été évaluée comme une dimension de sécurité à part entière.

Résultats des analyses SecurityHeaders.com pour les applications du fournisseur exposées à l’extérieur
Preuves de la configuration des en-têtes HTTP : en-têtes identifiant le serveur supprimés
Évaluation de la gestion des erreurs confirmant des réponses d’erreur génériques
Preuves de la gestion des métadonnées des documents
Confirmation du périmètre des tests d’intrusion incluant l’évaluation de la divulgation de métadonnées

À retenir

Les données étaient protégées. Les métadonnées racontaient ce que le chiffrement devait empêcher. La version du serveur dans l’en-tête HTTP. Le framework dans le message d’erreur. Le schéma de la base de données dans la structure des réponses de l’API. La classification interne dans la propriété du document. Rien de tout cela ne faisait partie des données protégées. Tout cela constituait la reconnaissance qui rendait l’attaque contre les données protégées bien plus efficace. La gouvernance des métadonnées est la discipline qui comble l’écart entre la protection de l’information et la protection de son contexte. Les contrôles des données principales couvrent les données. Les contrôles des métadonnées couvrent tout ce qui les entoure. N’évaluer que les contrôles principaux laisse le contexte environnant sans gouvernance, et c’est le contexte que les attaquants lisent en premier.