Scanner de sauvegardes téléchargeables

Comment fonctionne cette vérification

Scanaris demande neuf noms de fichiers que les gens utilisent encore et encore pour stocker des sauvegardes à la racine du site : backup.zip, backup.tar.gz, website.zip, www.zip, public_html.zip, site.zip, database.sql, dump.sql et db.sql. Pour chacun, il vérifie que la réponse est un vrai fichier et pas la page générique de ton site : il regarde le type de contenu et, pour les dumps SQL, que le texte ressemble à du SQL. Tous les constats sont de sévérité critique, parce qu'un tel fichier contient soit le code complet du site, soit la base de données entière.

Pourquoi c'est important

Un backup.zip accessible, c'est ton projet complet : code, configuration, les clés qui traînaient dans les fichiers et, souvent, une copie de la base dedans. Un dump.sql, c'est la base telle quelle : utilisateurs, e-mails, mots de passe hachés (attaquables à loisir), commandes, messages. Aucune technique nécessaire : c'est un téléchargement. Et les scanners automatiques essaient exactement ces noms contre tous les domaines qu'ils trouvent, donc « personne ne connaît l'URL » n'est pas une protection.

Pourquoi ça arrive

Par commodité au mauvais moment : avant une migration ou une mise à jour, on compresse le dossier du site « au cas où » et on le laisse là. Ou un plugin de sauvegarde écrit dans un dossier public. Ou un export de la base est enregistré à côté du code pour le passer à quelqu'un. Sur un serveur qui sert la racine du projet, tout fichier qui y atterrit est public instantanément.

Comment corriger

• Supprime le fichier maintenant et agis comme s'il avait été téléchargé : fais tourner toutes les clés et mots de passe qu'il contenait et, s'il y avait des données personnelles, évalue l'obligation de notifier.
• Déplace les sauvegardes hors du répertoire public. Les sauvegardes vont dans un stockage à part (un bucket privé, un autre serveur), jamais dans un dossier servi par le serveur web.
• Configure l'outil de sauvegarde pour écrire hors de la racine web. Les plugins WordPress permettent généralement de choisir le dossier ou d'envoyer vers un service externe.
• Bloque les extensions côté serveur comme seconde barrière. En nginx : location ~* \.(zip|tar|gz|sql|bak)$ { deny all; }. En Apache, un FilesMatch équivalent avec Require all denied. Si tu proposes légitimement des téléchargements compressés, limite-les à un dossier précis.
• Vérifie les journaux d'accès à la recherche de requêtes en 200 vers ces noms : ils te diront si quelqu'un est passé avant.

Vérifie que c'est corrigé

for p in backup.zip backup.tar.gz website.zip www.zip public_html.zip site.zip database.sql dump.sql db.sql; do
  printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://tondomaine.com/$p"
done

Attendu : 404 ou 403. Un 200 en text/html sur une application monopage, c'est son HTML générique ; un 200 en application/zip, application/octet-stream ou text/plain, c'est le vrai fichier.

Questions fréquentes

Ma sauvegarde a un nom que personne ne devinerait.

Les outils d'attaque essaient des milliers de noms et de combinaisons avec le domaine, la date et des mots comme « old » ou « bak ». Un nom inhabituel réduit le risque mais ne l'élimine pas ; la solution est qu'il ne soit pas dans un dossier public.

Et si le fichier est protégé par mot de passe ?

Un ZIP avec mot de passe se télécharge tout autant et s'attaque sans limite de tentatives sur l'ordinateur de l'attaquant. Ça reste un constat critique.

La vérification ne regarde que la racine. Et les sous-dossiers ?

Exact, ces neuf noms sont testés à la racine. Les listages de répertoires ouverts, que mesure une autre vérification, sont la façon habituelle de trouver des sauvegardes dans les sous-dossiers ; les fermer et bloquer les extensions couvre le reste.