Un chercheur en sécurité propose le standard security.txt à l'IETF
Un chercheur en sécurité propose le standard security.txt à l'IETF
pour permettre aux sites Web de définir leurs politiques de sécurité
Ed Foudil, un développeur web et chercheur de sécurité, a soumis un projet à l'IETF (Internet Engineering Task Force) en vue de la normalisation de security.txt, un fichier que les webmasters peuvent héberger sur leur domaine racine qui décrit les politiques de sécurité du site.
Dans le résumé qu’il a présenté à l’IETF, il rappelle que « Lorsque des indépendants, qui comprennent la gravité des risques, découvrent des failles de sécurité dans les services Web, ils manquent souvent de canaux pour les divulguer correctement. Par conséquent, les problèmes de sécurité peuvent ne pas être signalés. Security.txt définit un standard pour aider les organisations à définir le processus aux chercheurs afin qu’ils puissent divulguer de manière sécurisée les vulnérabilités qu’ils ont observées. »
Le fichier s'apparente à robots.txt, un fichier texte utilisé pour le référencement naturel des sites web, contenant des commandes à destination des robots d'indexation des moteurs de recherche afin de leur préciser les pages qui peuvent ou ne peuvent pas être indexées.
La différence entre security.txt et robots.txt est que security.txt sera utilisé pour communiquer uniquement sur les politiques de sécurité d'une entreprise et devrait être lu par les humains plutôt que par des bots.
Comment cela fonctionne-t-il ?
Le fichier /security.txt doit être situé sous /.well-known/ (/.well-known/security.txt) . Security.txt utilise une syntaxe similaire à robots.txt.
Voici une liste de toutes les options disponibles :
In-scope : définit les cibles dans leur portée. Vous pouvez utiliser des caractères génériques et ajouter vos applications bureautiques, applications mobiles et projets open source à la liste :
In-scope : * .example.com,
In-scope : github.com/example-project ;
Out-of-scope : définit les objectifs qui ne sont pas compris :
Out-of-scope, test.example.com ;
Out-of-scope-vuln : indique quelles vulnérabilités ne seront pas acceptées dans les rapports. Par exemple, si vous ne souhaitez pas que les chercheurs signalent les vulnérabilités de Clickjacking, vous pouvez procéder comme suit :
Out-of-scope-vuln : Clickjacking ;
Rate-limit : définit le nombre de demandes que les chercheurs peuvent envoyer par seconde :
Rate-limit: 1000 ;
Contact : Indique l’adresse que les chercheurs peuvent utiliser pour signaler des problèmes de sécurité :
Contact : security@example.com ;
PGP : Indique votre clé PGP. Vous pouvez directement ajouter votre clé PGP ou un lien vers une page qui contient votre clé :
PGP-key: ----- COMMENCEZ LE BLOC PGP CLE PUBLIQUE -----
...
----- TERMINEZ LE BLOC PGP CLE PUBLIQUE -----
PGP-key : http://example.com/pgp-key.txt
Security-page : fournit un lien vers la page de sécurité plus détaillée de votre entreprise :
Security-page : http://example.com/security
Platform : si votre entreprise utilise une plateforme de primes de bogues (HackerOne, Bugcrowd, etc.), vous pouvez l'ajouter avec cette option :
Plateform : https://hackerone.com/example
Payment-method : vous permet de préciser la méthode de paiement que votre entreprise utilisera pour récompenser un chercheur :
Payment-method : PayPal
Currency : vous permet de spécifier la devise de la récompense. Les codes de devise doivent être utilisés ici et non le symbole :
Currency : USD
Reward : vous permet d’indiquer aux chercheurs en sécurité à quel montant ils peuvent aspirer en guise de récompense en fonction de l'impact du problème :
Reward : Medium-200
Donate : attribuez-lui la valeur True si vous désirez faire correspondre les dons de récompenses. Cela signifie que si un chercheur veut faire un don de sa récompense, vous êtes prêt à faire correspondre leur don :
Donate : True
Disclosure : vous permet de spécifier votre politique de divulgation. Cela peut être un type de divulgation et/ou un délai (en jours) :
Disclosure : Full-30
Disallow : si vous ne souhaitez pas que les chercheurs en sécurité puissent tester votre plateforme, vous pouvez effectuer les opérations suivantes :
Disallow : *
Les commentaires peuvent être ajoutés en utilisant le symbole # :
# ceci est un commentaire.
Il est important de noter que vous avez besoin d'une ligne distincte pour tout ce que vous spécifiez. Vous ne pouvez pas faire une chaîne de caractères sur une seule ligne.
Out-of-scope-vuln : Clickjacking
Out-of-scope-vuln : Self-XSS
Out-of-scope-vuln : Open Redirect
En clair, d’après le projet qui a été proposé à l’IETF, un fichier security.txt pourrait ressembler à ceci :
#ceci est un exemple
Contact: security@exemple.com
Contact: +1-201-555-0123
Contact: https://exemple.com/securite
Encryption: https://exemple.com/pgp-key.txt
Disclosure: Full
Une idée qui a été plutôt bien accueillie par la communauté InfoSec
Foudil a expliqué que l’idée est née après qu’il a assisté à la conférence de sécurité DEF CON et à l'événement H1702 CTF aux États-Unis au début du mois d'août.
« Pendant ce temps, j'ai réfléchi aux contributions incroyables que certaines personnes des événements de Las Vegas faisaient à l'industrie de la sécurité et à notre société dans son ensemble », a-t-il expliqué. « Cela m'a motivé à cesser de garder mes idées pour moi-même et à commencer à travailler sur des projets et à partager mes idées. »
Il s’est alors inspiré de projets comme SECURITY.md et BUG-BOUNTY.md pour mettre en place une première version de la spécification security.txt qu'il a publiée plus tard sur GitHub. Les commentaires des membres de la communauté de sécurité l’ont convaincu de continuer.
« Lorsque x0rz [pseudonyme d’un chercheur en sécurité de renom] a tweeté à propos de ma proposition, j'ai réalisé que c'était quelque chose que les gens voulaient vraiment et qu'il était temps de commencer à rédiger un projet de dérogation RFC », a déclaré Foudil.
Le chercheur a reçu beaucoup de contributions de la part de la communauté. Il a expliqué que les commentaires sur les forums spécialisés l'ont aidé à façonner sa proposition IETF.
Des améliorations prévues
Le projet de sécurité IETF actuel de security.txt ne comprend que la prise en charge de quatre directives (Contact, Encryption, Disclosure et Acknowledgement) même si le projet GitHub en contient beaucoup plus. Foudil a expliqué la raison pour laquelle il a supprimé dans un premier temps la plupart des directives, qui, avec du recul, étaient très utiles et auraient donné plus de profondeur.
« Une grande entreprise de technologie m'a dit que je devais commencer tout doucement, voir comment les entreprises commencent à utiliser security.txt, puis, en m’appuyant sur leurs retours, je pourrais adapter security.txt en apportant de nouvelles directives. »
Source : dépôt IETF, dépôt GitHub
Et vous ?
:fleche: Qu'en pensez-vous ?
