kezako ?

Aujourd’hui, si vous détectez un problème de sécurité sur un site web ou un serveur que vous visitez, plusieurs freins peuvent vous empêcher de remonter convenablement la vulnérabilité.

En effet, retrouver le contact de l’administrateur du système peut parfois s’avérer laborieux et lorsque nous le trouvons, d’autres questions se posent :

• Est-ce la meilleure manière de lui remonter l’information ?
• A-t-il un canal de communication chiffré ?
• Comment va-t-il le prendre ?
• Est-ce qu’il peut se retourner contre nous ?

C’est entre autre à ces questions que tente de répondre le fichier security.txt. Son objectif est de centraliser ces informations en fournissant un cadre permettant la remontée d’information de sécurité.

Comment ça marche ?

Sa mise en oeuvre est relativement simple et est décrite en détails dans le draft de la RFC situé ici. Pour faire simple, il s’agit d’un simple fichier texte que l’administrateur du système doit placer à la racine de son serveur ou dans le dossier /.well-known/ de son site web. D’ailleurs, si vous ne connaissez pas ce dossier, je vous encourage à lire la RFC8615 qui décrit son rôle.

Plusieurs champs peuvent être définis dans ce fichier :

• Acknowledgements : Indique la page où sont remerciés les chercheurs ayant détectés une vulnérabilité
• Canonical : Indique l’adresse canonique où se situe le fichier security.txt
• Contact : Indique l’adresse de contact
• Encryption : Indique la clé permettant de chiffrer les communications
• Expires : Indique une date d’expiration après laquelle le contenu du fichier est considéré comme obsolète
• Hiring : Indique un lien vers les offres d’emplois de la société liées à la sécurité
• Policy : Indique un lien vers la politique de la société concernant la remontée de vulnérabilité
• Preferred-Languages : Indique quels langages sont à privilégier pour les échanges

Presque tous ces champs sont facultatifs et seul le champ Contact est obligatoire. Celui-ci doit contenir une URI vers l’adresse de contact, il s’agit souvent d’une adresse email, mais cela peut être un numéro de téléphone ou un formulaire de contact, l’important étant de respecter le format RFC3986.

Voici par exemple le fichier security.txt pour ce site :

Canonical: https://y0no.fr/.well-known/security.txt
Contact: mailto:security@y0no.fr
Encryption: https://y0no.fr/key.gpg
Preferred-Languages: en, fr

Afin de tenter de garantir l’intégrité de ce fichier, il est aussi possible de signer numériquement ce fichier à l’aide d’OpenPGP avec la commande gpg --clearsign /tmp/security.txt :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Canonical: https://y0no.fr/.well-known/security.txt
Contact: mailto:security@y0no.fr
Encryption: https://y0no.fr/key.gpg
Preferred-Languages: en, fr
-----BEGIN PGP SIGNATURE-----
<...>

Conclusion

Bien que ce fichier soit simple, il reste efficace et offre une souplesse permettant de s’adapter à chaque cas d’utilisation. Avec le nombre grandissant de chercheur en sécurité, ce type d’initiative est la bienvenue et permet de définir des règles simples et compréhensives de tous.

En plus, si la recherche de bugs vous botte bien, YesWeHack fournit une extension navigateur nommée YesWeHack VDP Finder qui permet de détecter la présence ou non d’un fichier security.txt

Si jamais vous trouvez une vulnérabilité sur un système qui ne semble pas utiliser le fichier security.txt, il est toujours possible de remonter les éléments par des intermediaire de confiance tels que Zerodisclo. Non ce n’est pas encore de la pub à YesWeHack, c’est juste qu’ils font les choses bien ;)