Security.txt

Fichier presque magique dont le nom de fichier (son format, et son emplacement) font référence à un draft de l’IETF.

Lorsqu’une vulnérabilité est détectée sur un site web (par un chercheur en sécurité, pentesteur, ou n’importe qui, etc…) pouvoir contacter le responsable du site web est peut-être l’une des premières étapes.

Le contact identifié dans un bas de page web, ou le formulaire contact mène parfois vers un service externalisé, un service comm qui peuvent n’avoir grand chose à faire du signalement d’une vulnérabilité (parfois). Alors l’alerte sur une vulnérabilité tombe aux oubliettes avant qu’elle ne soit exploitée par une autre personne mal intentionnée.

La mise en œuvre de ce fichier security.txt doit permettre de contacter les bonnes personnes pour le signalement d’une vulnérabilité du site web. Pour cela, le fichier doit être déposé dans un répertoire précis, sous un nom précis, avec un contenu de fichier standardisé.

La source de cet article est disponible ici : https://securitytxt.org/

Où mettre ce fichier : dans un répertoire à la racine du site web, sous le nom .well-know

Les informations à mentionner sont à minima :

  • Contact : un email,
  • Expires : la date d'expiration des informations contenues dans le fichier, date au format ISO 8601

En option, les informations peuvent être ajoutées (tous les liens seront en HTTPS) :

  • Encryption : l'url d'une clé de chiffrement destinée au chiffrement de la communication entre le découvrir et le responsable (par exemple, un fichier PGP)
  • Acknowledgements : l'url d'une page de remerciement/reconnaissance du signalement
  • Preferred-Languages : la langue préférée pour l'échange d'information
  • Canonical : l'url du fichier security.txt
  • Policy : l'url de politique de disclosure de l'entreprise pour appréhender les pratiques de reporting attendues par l'entreprise,
  • Hiring : un dernier lien sur les postes ouverts au recrutement dans le domaine de la cybersécurité.

A nouveau, le lien https://securitytxt.org/ est idéal car à jour des dernières évolution du draft, et surtout possède un formulaire qu’il suffit de compléter pour générer le fichier.

Vous voulez identifier si un site web contient ce fichier ? Soit par le navigateur, soit avec cette url : https://gotsecuritytxt.com en spécifiant le domaine requêté :

Par échantillonnage, vous constaterez le peu de fichiers présents sur les principaux sites web FR.

OpenVAS/GVM – scan de vulnérabilités

Concept d’OpenVAS

OpenVAS est  un framework, et un fork (ou une branche dérivée) de NESSUS. Nessus étant sous licence propriétaire, OpenVAS s’est développé sous licence GNU GPL.
Il est constitué d’éléments Backoffice :
– Scanner en charge du scan des vulnérabilités
-Manager qui contient toute l’intelligence du framework, il contrôle notamment le scanner, écrit dans la base SQLite. Il planifie, les audits, génère les reports, …
– Administator qui se charge de la gestion des utilisateurs, de l’alimentation en modèle de vulnérabilités ou en plugins.

Read more « OpenVAS/GVM – scan de vulnérabilités »

WordPress : liste de 24 points de sécurisation.

CMS parmi d’autres, WordPress permet comme les autres de créer et gérer facilement un site web, de le personnaliser à l’extrême, d’y ajouter des tonnes de fonctionnalités.

Bien que ce CMS soit l’un des plus infectés en 2018 sur internet (source Sucuri.net ), c’est aussi l’un des plus répandus, et qui bénéficie de nombreux articles pour le sécuriser.

L’objet de l’article n’est pas de faire la retape de WordPress mais de se concentrer sur les meilleurs moyens pour rendre son installation la plus securisée possible.

Les recommandations ci-dessous ne concernent pas les couches inférieures qui supportent WordPress (environnement virtuel ou physique, OS , moteur PHP,…). Tous ces éléments se doivent d’être à jour, bénéficier des derniers correctifs de sécurité, ne pas être obsolètes (EOL).

Très utile pour vérifier l’efficacité des mesures ci-dessous, quelques sites « d ‘audit » automatiques de votre propre CMS à la seule condition que vous en soyez le gestionnaire, propriétaire ou que vous ayez toutes les autorisations nécessaires (opérateur, hébergeur,…) avant de lancer ces tests.

Read more « WordPress : liste de 24 points de sécurisation. »