Table des matières
Au cours du week-end, j’ai vu un tweet de Troy Hunt qui proposait une petite idée de projet. Comme j’ai beaucoup de temps libre, je me suis dit que j’allais relever le défi et voir si je pouvais aider ! Je me suis dit que j’allais relever le défi et voir si je pouvais aider !
L’idée
Comme beaucoup d’entre vous le savent sans doute, Troy dirige J’ai été pwnéun site qui recense les violations de données et permet aux personnes ou aux organisations d’être alertées de leur exposition. Bien entendu, après une violation de données, on peut se demander si un site web prend la sécurité au sérieux, compte tenu de l’événement.
Vous cherchez un petit projet pour vous occuper pendant le week-end ? Je me disais justement : combien de sites web ayant fait l’objet d’une violation de données dans les pays de l’Union européenne ? @haveibeenpwned Vous avez maintenant un fichier security.txt ? Donc, si vous avez envie de récupérer ces domaines et de les interroger tous, il y a une API ici : https://t.co/ftiKkfH7Hp
– Troy Hunt (@troyhunt) 23 juillet 2023
Cela semble assez simple, mettons-nous au travail !
Crawler.Ninja
J’ai un autre projet appelé https://crawler.ninjaoù je scanne chaque jour les 1 000 000 premiers sites du monde et analyse divers aspects de leur sécurité. Vous pouvez consulter un résumé des données d’analyse quotidiennes ou accéder à une archive de toutes les données d’analyse historiques, mais attention, il y a maintenant plusieurs téraoctets ( !) de données historiques !
J’ai supprimé une partie du code du crawler car je recherche déjà la présence de la balise security.txt que Troy demandait, puis j’ai pu lancer l’analyse sur la liste des domaines ayant fait l’objet d’une brèche dans le HIBP. Il est facile d’obtenir la liste des domaines pour toutes les brèches dans HIBP, voici mon code pour le faire.
<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, 'https://haveibeenpwned.com/api/v3/breaches');
$response = curl_exec($ch);
$breachList = json_decode($response, true);
$domainList = [];
foreach ($breachList as $breach) {
if (isset($breach['Domain']) && trim(strtolower($breach['Domain'])) !== '') {
$domainList[] = trim(strtolower($breach['Domain']));
}
}
$domainList = array_unique($domainList);
foreach ($domainList as $domain) {
file_put_contents('output.txt', $domain . "\r\n", FILE_APPEND | LOCK_EX);
}Voici la liste des 641 domaines uniques que j’ai trouvés et que j’ai utilisés pour l’analyse.
Sécurité.txt
L’idée de la sécurité.txt est vraiment très simple et il est expliqué dans cet article de blog, mais le TLDR ; vous pouvez mettre des informations de contact dans un fichier texte dans cet emplacement spécifié pour que les gens puissent vous contacter quand les choses tournent mal. Vous pouvez voir que j’ai un de ces fichiers sur mes sites importants :
https://scotthelme.co.uk/.well-known/security.txt
https://securityheaders.com/.well-known/security.txt
https://report-uri.com/.well-known/security.txt
Il existe des exigences spécifiques quant à l’endroit où héberger ce fichier et à la manière de le présenter dans le document RFC 9116mais dans l’ensemble, il semble que les gens s’en sortent bien. Notamment ce qui suit :
Pour les services basés sur le web, les organisations DOIVENT placer le fichier « security.txt » sous le chemin « /.well-known/ ».
Le fichier DOIT être accessible via HTTP 1.0 ou une version plus récente, et l’accès au fichier DOIT utiliser le schéma « https ».
Il DOIT avoir un Content-Type de « text/plain » avec le paramètre charset par défaut réglé sur « utf-8 »
Ce champ [Contact] DOIT toujours être présent dans un fichier « security.txt ».
Il semble que le plus grand échec des sites qui tentent de répondre aux exigences soit d’avoir un fichier content-type de text\plain au lieu de la valeur requise de text\plain; charset=utf-8. Pour cette analyse, je vais adopter une approche un peu plus détendue et permettre à text\plain mais j’ai également fourni la liste des sites conformes à la vérification la plus stricte.
Sur le site contrôle strictseulement 6 sites sur les 641 vérifiés ont un fichier security.txt et sur les 641 sites vérifiés il y a un fichier security.txt. vérification détendueest légèrement meilleure à 11… Cela signifie que seulement 1,7 % de ces sites utilisent des fichiers security.txt !
En-têtes de sécurité
Pendant que je faisais cette analyse de sécurité, je me suis dit que je pouvais rapidement et facilement l’étendre pour y ajouter un peu plus de valeur. Les lecteurs réguliers connaissent mon En-têtes de sécurité projet qui a récemment rejoint Probelyoù vous pouvez faire un scan de sécurité gratuit de votre site web en ~2 secondes ! Security Headers a également une API j’ai donc écrit une rapide Client API pour comparer la liste des domaines HIBP avec l’API des en-têtes de sécurité. Vous pouvez voir la liste des domaines HIBP dans l’API des en-têtes de sécurité. résultats bruts pour faire votre propre analyse, mais je pense que ce graphique résume bien que les choses ne sont pas aussi bonnes qu’elles pourraient l’être.
Une poignée de domaines n’ont pas été résolus, certains ont carrément bloqué notre scanner et d’autres n’ont pas répondu au scanner, mais nous avons réussi à scanner 483 domaines figurant dans les données. Voici comment se répartissent les scores pour chacun d’entre eux.
| Note | Sites |
|---|---|
| A+ | 1 |
| A | 68 |
| B | 41 |
| C | 58 |
| D | 141 |
| E | 0 |
| F | 174 |
Étonnamment, ce n’est pas le cas aussi mais il n’y avait qu’un site unique qui a obtenu un A+, sur une liste de très, très grands sites.
Il sera intéressant de voir comment cela évolue à l’avenir et si la présence d’un fichier security.txt, ou même votre score sur Security Headers, peut être utilisé comme un indicateur du sérieux avec lequel vous prenez la sécurité ! 🤔
Vous voulez essayer le API des en-têtes de sécurité? Obtenez 10% de réduction sur vos 3 premiers mois avec HIBP10 à la caisse !