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é

Le , par Stéphane le calme, Chroniqueur Actualités
Security.txt vous semble-t-il un projet prometteur ?
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 ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de FMJ FMJ - Membre habitué https://www.developpez.com
le 22/09/2017 à 13:20
Pas grand chose visiblement. Ils doivent tous être occupé à ferrailler sur SWIFT !
Avatar de oudjira oudjira - Nouveau membre du Club https://www.developpez.com
le 22/09/2017 à 14:58
C'est vraiment une très bonne idée!!!
Avatar de jean12 jean12 - Membre à l'essai https://www.developpez.com
le 26/09/2017 à 12:55
Très bonne idée. Cela permettra aux administrateurs web une gestion plus professionnelle de leur tâches quotidiennes. Il faudrait toutefois rappeler les précautions à prendre pour rendre ce fichier inaccessible de l'extérieur.
Offres d'emploi IT
Développeur eZ Publish Expérimenté H/F Montpellier
Smile - Languedoc Roussillon - Montpellier (34000)
Tech Lead PHP H/F Montpellier
Smile - Languedoc Roussillon - Montpellier (34000)
Administrateur système & réseau / Maintenance interne
Intrasense - Languedoc Roussillon - Montpellier (34000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil