Examiner les métafichiers du serveur Web pour détecter les fuites d'informations

Résumé

Cette section décrit comment tester divers fichiers de métadonnées pour détecter les fuites d'informations sur les chemins ou les fonctionnalités de l'application web. De plus, la liste des répertoires à éviter par les araignées, les robots ou les crawlers peut également être créée en tant que dépendance pour Cartographier les chemins d'exécution à travers l'application. D'autres informations peuvent également être collectées pour identifier la surface d'attaque, les détails technologiques ou pour être utilisées dans le cadre d'une ingénierie sociale.

Objectifs du test

• Identifier les chemins et les fonctionnalités cachés ou obscurcis grâce à l'analyse des fichiers de métadonnées.
• Extraire et cartographier d'autres informations qui pourraient conduire à une meilleure compréhension des systèmes en question.

Comment tester

Toutes les actions effectuées ci-dessous avec wget peuvent également être effectuées avec curl. De nombreux outils de test de sécurité dynamique des applications (DAST) tels que ZAP et Burp Suite incluent des vérifications ou une analyse de ces ressources dans le cadre de leur fonctionnalité d'araignée/crawler. Elles peuvent également être identifiées en utilisant divers Google Dorks ou en tirant parti de fonctionnalités de recherche avancées telles que inurl:.

Robots

Les araignées, robots ou crawlers web récupèrent une page web, puis parcourent récursivement les hyperliens pour récupérer d'autres contenus web. Leur comportement accepté est spécifié par le Protocole d'exclusion des robots du fichier robots.txt dans le répertoire racine du site web.

A titre d'exemple, le début du fichier `robots.txt` de Google échantillonné le 5 mai 2020 est cité ci-dessous :

User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
Disallow: /sdch
...

La directive User-Agent fait référence à l'araignée/robot/crawler web spécifique. Par exemple, le `User-Agent: Googlebot` fait référence à l'araignée de Google tandis que `User-Agent: bingbot` fait référence à un crawler de Microsoft. `User-Agent: *` dans l'exemple ci-dessus s'applique à toutes les araignées/robots/crawlers web.

La directive `Disallow` spécifie les ressources interdites par les araignées/robots/crawlers. Dans l'exemple ci-dessus, les éléments suivants sont interdits :

...
Disallow: /search
...
Disallow: /sdch
...

Les araignées/robots/crawlers web peuvent intentionnellement ignorer les directives `Disallow` spécifiées dans un fichier `robots.txt`. Par conséquent, `robots.txt` ne doit pas être considéré comme un mécanisme pour appliquer des restrictions sur la façon dont le contenu web est accédé, stocké ou republié par des tiers.

Le fichier `robots.txt` est récupéré à partir du répertoire racine du serveur web. Par exemple, pour récupérer le `robots.txt` de `www.google.com` en utilisant `wget` ou `curl` :

$ curl -O -Ss https://www.google.com/robots.txt && head -n5 robots.txt
User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
...

Analyser robots.txt à l'aide des outils pour les webmasters de Google

Les propriétaires de sites peuvent utiliser la fonction "Analyser robots.txt" de Google pour analyser le site dans le cadre de ses outils pour les webmasters de Google. Cet outil peut aider aux tests et la procédure est la suivante :

1. Connectez-vous aux outils pour les webmasters de Google avec un compte Google.
2. Sur le tableau de bord, entrez l'URL du site à analyser.
3. Choisissez entre les méthodes disponibles et suivez les instructions à l'écran.

Balises META

Les balises `<META>` sont situées dans la section `HEAD` de chaque document HTML et doivent être cohérentes sur un site dans le cas où le point de départ du robot/araignée/crawler ne commence pas à partir d'un lien de document autre que la racine du site web, c'est-à-dire un lien profond. La directive Robots peut également être spécifiée à l'aide d'une balise META spécifique.

Balise META Robots

S'il n'y a pas d'entrée `<META NAME="ROBOTS" ... >`, alors le "Protocole d'exclusion des robots" prend par défaut la valeur `INDEX,FOLLOW` respectivement. Par conséquent, les deux autres entrées valides définies par le "Protocole d'exclusion des robots" sont préfixées par `NO...`, c'est-à-dire `NOINDEX` et `NOFOLLOW`.

Sur la base des directives Disallow listées dans le fichier `robots.txt` dans la racine web, une recherche d'expression régulière pour `<META NAME="ROBOTS"` est effectuée dans chaque page web. Le résultat est ensuite comparé au fichier robots.txt dans la racine web.

Balises META d'informations diverses

Les organisations intègrent souvent des balises META d'information dans le contenu web pour prendre en charge diverses technologies telles que les lecteurs d'écran, les aperçus de réseaux sociaux, l'indexation des moteurs de recherche, etc. Ces méta-informations peuvent être utiles aux testeurs pour identifier les technologies utilisées et les chemins/fonctionnalités supplémentaires à explorer et à tester. Les méta-informations suivantes ont été récupérées de `www.whitehouse.gov` via l'affichage de la source de la page le 5 mai 2020 :

<meta property="og:locale" content="en_US" />
<meta property="og:type" content="website" />
<meta property="og:title" content="The White House" />
<meta property="og:description" content="Nous, les citoyens d'Amérique, sommes maintenant réunis dans un grand effort national pour reconstruire notre pays et restaurer sa promesse pour tous. – Président Donald Trump." />
<meta property="og:url" content="https://www.whitehouse.gov/" />
<meta property="og:site_name" content="The White House" />
<meta property="fb:app_id" content="1790466490985150" />
<meta property="og:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta property="og:image:secure_url" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:description" content="Nous, les citoyens d'Amérique, sommes maintenant réunis dans un grand effort national pour reconstruire notre pays et restaurer sa promesse pour tous. – Président Donald Trump." />
<meta name="twitter:title" content="The White House" />
<meta name="twitter:site" content="@whitehouse" />
<meta name="twitter:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta name="twitter:creator" content="@whitehouse" />
...
<meta name="apple-mobile-web-app-title" content="The White House">
<meta name="application-name" content="The White House">
<meta name="msapplication-TileColor" content="#0c2644">
<meta name="theme-color" content="#f5f5f5">
...

Plans de site

Un plan de site est un fichier dans lequel un développeur ou une organisation peut fournir des informations sur les pages, les vidéos et les autres fichiers proposés par le site ou l'application, ainsi que sur les relations entre eux. Les moteurs de recherche peuvent utiliser ce fichier pour naviguer plus efficacement sur votre site. De même, les testeurs peuvent utiliser les fichiers 'sitemap.xml' pour obtenir des informations plus approfondies sur le site ou l'application étudiée.

L'extrait suivant provient du plan de site principal de Google récupéré le 5 mai 2020.

$ wget --no-verbose https://www.google.com/sitemap.xml && head -n8 sitemap.xml
2020-05-05 12:23:30 URL:https://www.google.com/sitemap.xml [2049] -> "sitemap.xml" [1]

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="https://www.google.com/schemas/sitemap/0.84">
  <sitemap>
    <loc>https://www.google.com/gmail/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/forms/sitemaps.xml</loc>
  </sitemap>
...

En explorant à partir de là, un testeur peut souhaiter récupérer le plan de site de gmail `https://www.google.com/gmail/sitemap.xml` :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="https://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="https://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.google.com/intl/am/gmail/about/</loc>
    <xhtml:link href="https://www.google.com/gmail/about/" hreflang="x-default" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/el/gmail/about/" hreflang="el" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/it/gmail/about/" hreflang="it" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/ar/gmail/about/" hreflang="ar" rel="alternate"/>
...

TXT de sécurité

security.txt a été ratifié par l'IETF en tant que RFC 9116 - Un format de fichier pour aider à la divulgation des vulnérabilités de sécurité qui permet aux sites de définir des politiques de sécurité et des coordonnées. Il y a plusieurs raisons pour lesquelles cela pourrait être intéressant dans les scénarios de test, qui incluent, mais ne sont pas limitées à :

• Identifier d'autres chemins ou ressources à inclure dans la découverte/l'analyse.
• Collecte de renseignements open source.
• Trouver des informations sur les Bug Bounties, etc.
• Ingénierie sociale.

Le fichier peut être présent soit à la racine du serveur web, soit dans le répertoire .well-known/, par exemple :

• `https://example.com/security.txt`
• `https://example.com/.well-known/security.txt`

Voici un exemple concret récupéré de LinkedIn le 5 mai 2020 :

$ wget --no-verbose https://www.linkedin.com/.well-known/security.txt && cat security.txt
2020-05-07 12:56:51 URL:https://www.linkedin.com/.well-known/security.txt [333/333] -> "security.txt" [1]
# Conforms to IETF `draft-foudil-securitytxt-07`
Contact: mailto:security@linkedin.com
Contact: https://www.linkedin.com/help/linkedin/answer/62924
Encryption: https://www.linkedin.com/help/linkedin/answer/79676
Canonical: https://www.linkedin.com/.well-known/security.txt
Policy: https://www.linkedin.com/help/linkedin/answer/62924

Les clés publiques OpenPGP contiennent des métadonnées qui peuvent fournir des informations sur la clé elle-même. Voici quelques éléments de métadonnées courants qui peuvent être extraits d'une clé publique OpenPGP :

• ID de clé : L'ID de clé est un identifiant court dérivé du matériau de la clé publique. Il aide à identifier la clé et est souvent affiché sous forme de valeur hexadécimale de huit caractères.
• Empreinte de clé : L'empreinte de clé est un identifiant plus long et plus unique dérivé du matériau de la clé. Elle est souvent affichée sous forme de valeur hexadécimale de 40 caractères. Les empreintes de clé sont couramment utilisées pour vérifier l'intégrité et l'authenticité d'une clé publique.
• Algorithme de clé : L'algorithme de clé représente l'algorithme cryptographique utilisé par la clé publique. OpenPGP prend en charge divers algorithmes tels que RSA, DSA et ECC (cryptographie sur les courbes elliptiques).
• Taille de la clé : La taille de la clé fait référence à la longueur ou à la taille de la clé cryptographique en bits. Elle indique la force de la clé et détermine le niveau de sécurité fourni par la clé.
• Date de création de la clé : La date de création de la clé indique quand la clé a été générée ou créée.
• Date d'expiration de la clé : Les clés publiques OpenPGP peuvent avoir une date d'expiration définie, après laquelle elles sont considérées comme invalides. La date d'expiration de la clé spécifie quand la clé n'est plus valide.
• ID utilisateur : Les clés publiques peuvent avoir un ou plusieurs ID utilisateur associés qui identifient le propriétaire ou l'entité associée à la clé. Les ID utilisateur incluent généralement des informations telles que le nom, l'adresse e-mail et les commentaires facultatifs du propriétaire de la clé.

TXT des humains

humans.txt est une initiative pour connaître les personnes derrière un site. Il prend la forme d'un fichier texte qui contient des informations sur les différentes personnes qui ont contribué à la construction du site. Ce fichier contient souvent (mais pas toujours) des informations relatives aux carrières ou aux sites/chemins d'emploi.

L'exemple suivant a été récupéré de Google le 5 mai 2020 :

$ wget --no-verbose https://www.google.com/humans.txt && cat humans.txt
2020-05-07 12:57:52 URL:https://www.google.com/humans.txt [286/286] -> "humans.txt" [1]
Google est construit par une grande équipe d'ingénieurs, de concepteurs, de chercheurs, de robots et autres dans de nombreux sites différents à travers le monde. Il est mis à jour en continu et construit avec plus d'outils et de technologies que nous ne pouvons en compter. Si vous souhaitez nous aider, consultez careers.google.com.

Autres sources d'informations .well-known

Il existe d'autres RFC et brouillons Internet qui suggèrent des utilisations standardisées des fichiers dans le répertoire .well-known/. Des listes de ceux-ci peuvent être trouvées ici ou ici.

Il serait assez simple pour un testeur d'examiner les RFC/brouillons et de créer une liste à fournir à un crawler ou à un fuzzer, afin de vérifier l'existence ou le contenu de ces fichiers.

Outils

• Navigateur (fonctionnalité Afficher la source ou Outils de développement)
• curl
• wget
• Burp Suite
• ZAP