Contactez-nous

Examiner le contenu des pages Web pour détecter les fuites d'informations

Comment examiner les commentaires HTML, les métadonnées, le code JavaScript et les fichiers de débogage (comme les fichiers source map) pour identifier les fuites d'informations potentielles sur une application web.

ID
WSTG-INFO-05

Résumé

Il est très courant, et même recommandé, que les programmeurs incluent des commentaires détaillés et des métadonnées dans leur code source. Cependant, les commentaires et les métadonnées inclus dans le code HTML peuvent révéler des informations internes qui ne devraient pas être accessibles aux attaquants potentiels. L'examen des commentaires et des métadonnées doit être effectué afin de déterminer si des informations sont divulguées. De plus, certaines applications peuvent divulguer des informations dans le corps des réponses de redirection.

Pour les applications web modernes, l'utilisation de JavaScript côté client pour le frontend devient de plus en plus populaire. Les technologies populaires de construction de frontend utilisent du JavaScript côté client comme ReactJS, AngularJS ou Vue. Similaire aux commentaires et métadonnées dans le code HTML, de nombreux programmeurs codent également en dur des informations sensibles dans des variables JavaScript sur le frontend. Les informations sensibles peuvent inclure (mais ne sont pas limitées à) : des clés API privées (*par exemple* une clé API Google Map non restreinte), des adresses IP internes, des routes sensibles (*par exemple* une route vers des pages ou des fonctionnalités d'administration cachées), ou même des informations d'identification. Ces informations sensibles peuvent être divulguées à partir d'un tel code JavaScript frontend. Un examen doit être effectué afin de déterminer si des informations sensibles sont divulguées qui pourraient être utilisées par des attaquants à des fins abusives.

Pour les applications web volumineuses, les problèmes de performances sont une grande préoccupation pour les programmeurs. Les programmeurs ont utilisé différentes méthodes pour optimiser les performances du frontend, notamment Syntactically Awesome Style Sheets (Sass), Sassy CSS (SCSS), webpack, etc. En utilisant ces technologies, le code frontend deviendra parfois plus difficile à comprendre et à déboguer, et à cause de cela, les programmeurs déploient souvent des fichiers source map à des fins de débogage. Une "source map" est un fichier spécial qui relie une version minifiée/uglifiée d'un actif (CSS ou JavaScript) à la version originale créée. Les programmeurs débattent encore de la question de savoir s'il faut apporter des fichiers source map dans l'environnement de production. Cependant, il est indéniable que les fichiers source map ou les fichiers de débogage, s'ils sont publiés dans l'environnement de production, rendront leur source plus lisible par l'homme. Cela peut faciliter la tâche des attaquants pour trouver des vulnérabilités depuis le frontend ou collecter des informations sensibles à partir de celui-ci. La revue du code JavaScript doit être effectuée afin de déterminer si des fichiers de débogage sont exposés depuis le frontend. Selon le contexte et la sensibilité du projet, un expert en sécurité doit décider si les fichiers doivent exister dans l'environnement de production ou non.

Objectifs du test

  • Examiner les commentaires, les métadonnées et le corps des redirections des pages web pour détecter toute fuite d'informations.
  • Rassembler les fichiers JavaScript et examiner le code JS pour mieux comprendre l'application et trouver toute fuite d'informations.
  • Identifier si des fichiers source map ou d'autres fichiers de débogage frontend existent.

Comment tester

Examiner les commentaires et les métadonnées des pages Web

Les commentaires HTML sont souvent utilisés par les développeurs pour inclure des informations de débogage sur l'application. Parfois, ils oublient les commentaires et les laissent dans les environnements de production. Les testeurs doivent rechercher les commentaires HTML qui commencent par <!--.

Vérifiez le code source HTML pour les commentaires contenant des informations sensibles qui peuvent aider l'attaquant à mieux comprendre l'application. Il peut s'agir de code SQL, de noms d'utilisateur et de mots de passe, d'adresses IP internes ou d'informations de débogage.

...
<div class="table2">
  <div class="col1">1</div><div class="col2">Mary</div>
  <div class="col1">2</div><div class="col2">Peter</div>
  <div class="col1">3</div><div class="col2">Joe</div>

<!-- Query: SELECT id, name FROM app.users WHERE active='1' -->

</div>
...

Le testeur peut même trouver quelque chose comme ceci :

<!-- Use the DB administrator password for testing: f@keP@a$$w0rD -->

Vérifiez les informations de version HTML pour les numéros de version valides et les URL de définition de type de document (DTD)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
  • strict.dtd -- DTD strict par défaut
  • loose.dtd -- DTD souple
  • frameset.dtd -- DTD pour les documents frameset

Certaines balises META ne fournissent pas de vecteurs d'attaque actifs mais permettent plutôt à un attaquant de profiler une application :

<META name="Author" content="Andrew Muller">

Une balise META courante (mais non conforme à WCAG) est Refresh.

<META http-equiv="Refresh" content="15;URL=https://www.owasp.org/index.html">

Une utilisation courante de la balise META consiste à spécifier des mots-clés qu'un moteur de recherche peut utiliser pour améliorer la qualité des résultats de recherche.

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

Bien que la plupart des serveurs web gèrent l'indexation des moteurs de recherche via le fichier robots.txt, elle peut également être gérée par des balises META. La balise ci-dessous conseillera aux robots de ne pas indexer et de ne pas suivre les liens sur la page HTML contenant la balise.

<META name="robots" content="none">

La Plateforme pour la sélection du contenu Internet (PICS) et le Protocole pour les ressources de description web (POWDER) fournissent une infrastructure pour associer des métadonnées au contenu Internet.

Identifier le code JavaScript et rassembler les fichiers JavaScript

Les programmeurs codent souvent en dur des informations sensibles avec des variables JavaScript sur le frontend. Les testeurs doivent vérifier le code source HTML et rechercher le code JavaScript entre les balises <script> et </script>. Les testeurs doivent également identifier les fichiers JavaScript externes pour examiner le code (les fichiers JavaScript ont l'extension de fichier .js et le nom du fichier JavaScript est généralement placé dans l'attribut src (source) d'une balise <script>).

Vérifiez le code JavaScript pour toute fuite d'informations sensibles qui pourrait être utilisée par des attaquants pour abuser ou manipuler davantage le système. Recherchez des valeurs telles que : des clés API, des adresses IP internes, des routes sensibles ou des informations d'identification. Par exemple :

const myS3Credentials = {
  accessKeyId: config('AWSS3AccessKeyID'),
  secretAccessKey: config('AWSS3SecretAccessKey'),
};

Le testeur peut même trouver quelque chose comme ceci :

var conString = "tcp://postgres:1234@localhost/postgres";

Lorsqu'une clé API est trouvée, les testeurs peuvent vérifier si les restrictions de clé API sont définies par service ou par IP, référent HTTP, application, SDK, etc.

Par exemple, si les testeurs trouvent une clé API Google Map, ils peuvent vérifier si cette clé API est limitée par IP ou uniquement par les API Google Map. Si la clé API Google est limitée uniquement par les API Google Map, les attaquants peuvent toujours utiliser cette clé API pour interroger les API Google Map non restreintes et le propriétaire de l'application doit payer pour cela.

<script type="application/json">
...
{"GOOGLE_MAP_API_KEY":"AIzaSyDUEBnKgwiqMNpDplT6ozE4Z0XxuAbqDi4", "RECAPTCHA_KEY":"6LcPscEUiAAAAHOwwM3fGvIx9rsPYUq62uRhGjJ0"}
...
</script>

Dans certains cas, les testeurs peuvent trouver des routes sensibles à partir du code JavaScript, telles que des liens vers des pages d'administration internes ou cachées.

<script type="application/json">
...
"runtimeConfig":{"BASE_URL_VOUCHER_API":"https://staging-voucher.victim.net/api", "BASE_BACKOFFICE_API":"https://10.10.10.2/api", "ADMIN_PAGE":"/hidden_administrator"}
...
</script>

Identifier les fichiers Source Map

Les fichiers source map seront généralement chargés lorsque DevTools s'ouvre. Les testeurs peuvent également trouver des fichiers source map en ajoutant l'extension ".map" après l'extension de chaque fichier JavaScript externe. Par exemple, si un testeur voit un fichier /static/js/main.chunk.js, il peut alors vérifier son fichier source map en visitant /static/js/main.chunk.js.map.

Vérifiez les fichiers source map pour toute information sensible qui peut aider l'attaquant à mieux comprendre l'application. Par exemple :

{
  "version": 3,
  "file": "static/js/main.chunk.js",
  "sources": [
    "/home/sysadmin/cashsystem/src/actions/index.js",
    "/home/sysadmin/cashsystem/src/actions/reportAction.js",
    "/home/sysadmin/cashsystem/src/actions/cashoutAction.js",
    "/home/sysadmin/cashsystem/src/actions/userAction.js",
    "..."
  ],
  "..."
}

Lorsque les sites chargent des fichiers source map, le code source du frontend deviendra lisible et plus facile à déboguer.

Identifier les réponses de redirection qui divulguent des informations

Bien que les réponses de redirection ne soient généralement pas censées contenir de contenu web significatif, il n'y a aucune assurance qu'elles ne peuvent pas contenir de contenu. Ainsi, alors que les réponses de la série 300 (redirection) contiennent souvent un contenu de type "redirection vers https://example.com/", elles peuvent également divulguer du contenu.

Considérez une situation dans laquelle une réponse de redirection est le résultat d'une vérification d'authentification ou d'autorisation, si cette vérification échoue, le serveur peut répondre en redirigeant l'utilisateur vers une page "sûre" ou "par défaut", mais la réponse de redirection elle-même peut toujours contenir du contenu qui n'est pas affiché dans le navigateur mais qui est effectivement transmis au client. Cela peut être vu soit en utilisant les outils de développement du navigateur, soit via un proxy personnel (tel que ZAP, Burp, Fiddler ou Charles).

Outils

Références

Livres blancs