Quand on ouvre le capot d'un site de PME, on ne trouve presque jamais une attaque sophistiquée. On trouve sept négligences, toujours les mêmes, et qui n'ont presque rien à voir avec la technique. Elles ont à voir avec le fait que personne n'a jamais eu le temps.
Voici ces sept failles, ce qui les provoque, et ce qu'il faut faire pour chacune.
1. Le site n'a pas été mis à jour depuis sa livraison
C'est la première et la plus répandue. Le prestataire livre un site fonctionnel, le client paie, et plus personne n'y touche. Deux ans plus tard, le gestionnaire de contenu et ses extensions accusent une trentaine de versions de retard.
Le problème n'est pas que les anciennes versions soient mauvaises. Le problème est que chaque mise à jour publie, en même temps, la liste des failles qu'elle corrige. Un site non mis à jour n'est pas un site inconnu des attaquants : c'est un site dont les faiblesses sont publiées et documentées.
Ce qu'il faut faire : une mise à jour mensuelle, précédée d'une sauvegarde, sur un environnement de test quand le site est sensible. C'est une heure par mois, pas un projet.
2. Un seul compte administrateur, et son mot de passe circule
Le compte s'appelle souvent admin. Le mot de passe a été choisi le jour de la livraison, il est encore en place, et il est connu du prestataire, du stagiaire qui a mis à jour le catalogue, et de la personne qui gère la page Facebook.
Aucune double authentification. Aucun moyen de savoir qui s'est connecté.
Ce qu'il faut faire : un compte nominatif par personne, avec le niveau de droits minimal dont elle a besoin. La double authentification activée sur les comptes administrateurs. Et la suppression des comptes des gens qui ne travaillent plus avec vous, ce qui est l'oubli le plus fréquent.
3. Les sauvegardes existent, mais personne ne les a jamais restaurées
Presque toutes les PME ont une sauvegarde. Presque aucune ne l'a testée.
On découvre le jour de l'incident que la sauvegarde ne contenait que les fichiers et pas la base de données, ou qu'elle tourne depuis huit mois sur un disque plein, ou qu'elle sauvegarde fidèlement le site déjà compromis.
Ce qu'il faut faire : une restauration complète, une fois, sur un environnement séparé, chronomètre en main. Vous saurez alors deux choses que vous ignorez aujourd'hui : si votre sauvegarde fonctionne, et combien d'heures il vous faut pour remettre le site en ligne.
4. Le formulaire de contact accepte tout
Un formulaire sans limitation de débit, sans vérification du contenu, et qui accepte les pièces jointes sans filtrer leur type. C'est la porte d'entrée la plus discrète d'un site vitrine.
Les conséquences vont du désagrément à l'incident sérieux : boîte mail saturée, serveur utilisé pour relayer du spam, et dans les cas les plus lourds, un fichier déposé sur le serveur.
Ce qu'il faut faire : limiter le nombre d'envois par adresse et par heure, n'autoriser que les types de fichiers réellement nécessaires, et stocker les pièces jointes en dehors du répertoire public du site.
5. Le HTTPS est là, mais mal posé
Le cadenas s'affiche, donc on considère le sujet réglé. Dans les faits, on trouve régulièrement un certificat expiré depuis plusieurs semaines, des pages qui chargent encore des images ou des scripts en HTTP, ou une version non sécurisée du site toujours accessible en parallèle.
Sur un site qui encaisse des paiements, ce détail n'en est pas un.
Ce qu'il faut faire : redirection automatique de toutes les URL vers HTTPS, renouvellement automatique du certificat, et vérification qu'aucune ressource de la page ne charge en clair.
6. Les identifiants sont écrits dans le code
Clés d'API de paiement, identifiants de base de données, jetons d'accès : on les trouve écrits en dur dans un fichier du site, parfois dans un fichier de sauvegarde resté accessible, parfois dans un dépôt de code public.
Cette faille est particulièrement coûteuse quand elle concerne des clés de paiement mobile, parce que ce qui fuit alors n'est pas une donnée mais un moyen d'encaisser.
Ce qu'il faut faire : sortir tous les secrets du code et les placer dans des variables d'environnement. Vérifier qu'aucun fichier de configuration ou de sauvegarde n'est accessible depuis un navigateur. Et changer toute clé qui a un jour été écrite dans un fichier partagé, parce qu'on ne sait jamais où elle a été copiée.
7. Il n'y a aucun journal, donc aucune détection
C'est la septième et c'est celle qui transforme un incident en catastrophe. Sans journal de connexion ni supervision, une intrusion n'est pas détectée. Elle est découverte, des semaines plus tard, parce qu'un client signale que le site affiche autre chose, ou parce que le moteur de recherche l'a déclassé.
Entre-temps, l'attaquant a eu tout le temps de s'installer, et vos sauvegardes récentes contiennent déjà sa présence.
Ce qu'il faut faire : conserver les journaux de connexion et de modification, et mettre en place une alerte sur les événements simples : échecs de connexion répétés, création d'un compte administrateur, modification d'un fichier système. Ce n'est pas de la supervision d'entreprise, c'est le minimum pour savoir.
Ce que ces sept points ont en commun
Aucune de ces failles ne demande de compétence rare pour être corrigée. Aucune ne coûte cher. Elles sont là parce qu'un site est considéré comme terminé le jour de sa mise en ligne, alors qu'un site est une installation qui fonctionne en continu et qui demande le même entretien qu'une installation électrique.
Si vous ne devez en traiter qu'une cette semaine, prenez la troisième. Restaurez votre sauvegarde sur un environnement de test et regardez ce qui remonte. C'est le test le plus rapide, et c'est celui qui révèle le plus de choses.
Vous voulez savoir lesquelles de ces sept failles concernent votre site ? Nous réalisons des audits de sécurité avec rapport sous dix jours. Demander un devis.