Sécuriser un site sur les pages perso

Les Pages Perso Chez Free

Par Al, le , dans Éviter les problèmes. / Dernière modification : le par Al, (merci à merci à Coyote mal reveillé, le 19 septembre 2012 ajout de « Quelques notions de sécurité pour les pages dynamiques développées par vous-même. » par Otomatic).
Tags : MySQL, PostgreSQL, Sécurité, Apache, Console de gestion, Erreur 403, Erreur 500, Fonction mail(), Phishing, Spam, PHP

La sécurité d'un site internet est un processus complexe qu'il ne faut pas prendre à la légère. En effet, mettre à la disponibilité du public un site internet implique un certain nombre de responsabilités inhérentes à cette activité. En tant qu'hébergeur, Free réalise les mises à jour d'usage sur les serveurs, mais son rôle ne consiste pas à mettre à jour et sécuriser les sites des utilisateurs, qui sont souvent ceux qui présentent les failles de sécurité permettant les intrusions sur les sites. Free assure la sécurité du « contenant », pas du « contenu ».

Comme l'indiquent les développeurs d'OpenBSD, « la sécurité n'est pas un produit, mais un processus. » Voici quelques règles simples permettant de se prémunir des intrusions et de sécuriser son site internet.

Généralités

« Internet n'est pas un bac à sable ! » répète à l'envie le responsable du service des Pages Perso. C'est effectivement le cas, les sites Web, les adresses de courriels et les comptes utilisateurs sont sous la menace permanente d'internautes et de robots peu scrupuleux. Il n'existe pas non plus de « logiciel » résolvant l'ensemble des problèmes de sécurité.

Aucun site web n'est sûr à 100%. La société Free assure la sécurité du « contenant » (serveurs, système de base de données…), mais pas des données elles-mêmes. Il vous incombe de sauvegarder vos données, sécuriser vos accès, vos CMS et scripts PHP et JavaScript, vos requêtes SQL, etc. en gardant en mémoire qu'il ne faut jamais faire confiance à l'utilisateur qui visite votre site.

La règle de base : utilisez des outils et des langages de programmation que vous maîtrisez. Il n'y a pas de honte à créer un site en HTML (surtout avec les derniers développements du HTML5/CSS3), d'utiliser des SSI au lieu de PHP, etc. Vous pouvez également confier le développement et la maintenance de votre site à une personne de confiance disposant des compétences nécessaires à votre projet. Maintenez également à jour votre ordinateur personnel (système d'exploitation et logiciels installés).

Première ligne de défense : les mots de passe. Free offre la possibilité de personnaliser les mots de passe de vos comptes et des accès FTP et SQL. Il est important de choisir des mots de passe robustes et différenciés. Tout est expliqué dans un billet de ce site.

Seconde ligne de défense : le serveur Apache. Il est administré et configuré par Free de manière stricte, mais vous pouvez en augmenter encore la sécurité à l'aide des directives que vous pouvez placer dans les fichiers .htaccess. Il est essentiel de limiter l'accès au listing des répertoires de votre site via la directive Options -Indexes. Ainsi, les visiteurs ne peuvent visualiser le contenu des répertoires, ils doivent suivre les liens présentés dans vos pages. Vous pouvez également limiter ou interdire l'accès extérieur à certaines ressources sensibles de votre site. De même, selon la nature de votre site, il peut être intéressant de désactiver certaines fonctions du serveur qui vous sont inutiles (inclusion de fichier, utilisation de scripts PHP…). Il faut dans ce cas regarder du côté des fichiers .htaccess.

Troisième ligne de défense : les scripts. Les langages de programmation serveur (PHP/SQL) sont des langages puissants vous permettant d'interagir avec votre compte pour éditer, créer ou supprimer des données. Il faut toujours être certain que les données que vous exploitez depuis les pages de votre site ont été vérifiées et sont conformes à ce que vous attendez. Il ne faut jamais utiliser une variable provenant de « l'extérieur » sans en avoir vérifié le contenu ou la valeur au préalable. De plus, les langages de programmation sont tous sujets à des failles de sécurité. Que vos pages soient écrites par vous-même ou que vous utilisiez un CMS ou des scripts/frameworks clef-en-main, il vous incombe de suivre les bulletins d'information publiés par les développeurs de ces langages, scripts/frameworks ou CMS (ainsi que leurs extensions tierces) et d'appliquer les correctifs publiés. Suivez les recommandations de sécurité proposées par les communautés de développeurs des scripts et CMS que vous utilisez. Toutefois, n'appliquez jamais ce que ne vous ne comprenez pas parfaitement. Il est en effet préférable de comprendre les procédures et les modifications avant de les appliquer, afin d'en comprendre l'utilité, les risques ou les effets de bord qui en résulterait.

Quatrième ligne de défense : surveiller votre site. Il est essentiel de vérifier régulièrement votre site pour y déceler des « signes » suspects. Cette vérification doit inclure une vérification visuelle, une vérification de la présence de fichier(s) que vous n'avez pas placé(s) vous-même (à l'aide de ⬇︎ ce script), une vérification des dates de modification et création des fichiers et des répertoires ainsi que des entrées dans la base SQL, une vérification des fichiers par anti-virus/anti-malware (notamment les archives) ainsi qu'une une vérification du code de votre site à la recherche de morceaux de codes malicieux, de iframe/frame vérolées, de directives « étranges » dans les fichiers .htaccess

Dernière ligne de défense : la protection de vos formulaires et de votre site contre le « spam » et les robots par deny from dans le .htaccess et captcha, ainsi qu'une bonne gestion de l'indexation de votre site par les robots des moteurs de recherche (fichiers robots.txt, en-tête HTTP X-Robots-Tag ou balise <meta name="robots"…> afin d'éviter que ces mêmes moteurs de recherche puissent servir de relais à la découverte de failles de sécurité de votre site.

Ne communiquez jamais vos identifiants à des tiers, ou sur des sites Web dont vous n'êtes pas certains qu'ils appartiennent à la société Free et utilisent un protocole chiffré (https://…). De la même manière, ne communiquez jamais vos mots de passe sur le forum Usenet d'assistance des Pages Perso. Abstenez-vous de vous connecter à votre compte depuis des ordinateurs dont vous n'êtes pas sûr de la sécurité (préférez des systèmes d'exploitation sur supports amovibles). Nous vous encourageons également à suivre les bonnes pratiques de navigation et de sécurité informatique.

Vos ordinateurs, tablettes et mobiles

Il est essentiel de maintenir les appareils que vous utilisez pour gérer votre site (accès FTP ou accès à l'interface d'administration) à jour, pour vous protéger des attaques, vulnérabilités et compromissions pouvant entrainer, à leur tour, le piratage de votre compte, le contournement de la politique de sécurité de vos logiciels ou de votre site Web ou la divulgation de données confidentielles.

Liens utiles

Les mots de passe

Tout est expliqué sur une page de ce site. Elle présente les procédures pour modifier et diversifier vos mots de passe pour votre compte, votre accès FTP et votre base SQL.

Liens utiles

Faire les mises à jour de vos scripts

Les gestionnaires de contenu (CMS) écrit en PHP sont régulièrement sujets à des failles de sécurité. Les développeurs de ces logiciels publient des correctifs qu'il faut appliquer régulièrement afin de protéger son site des intrusions, bien avant la correction de bugs et l'ajout de nouvelles fonctionnalités.

Votre compte permet l'utilisation du langage de scripts PHP. PHP est un langage puissant qui permet, à travers internet, d'interagir avec votre compte d’hébergement en créant, modifiant, supprimant des fichiers, en exécutant des commandes systèmes, etc. De nombreux webmasters utilisent des CMS tels que Joomla!, WordPress, Dotclear, etc. : s'ils permettent de déployer facilement un site Internet, ils sont également les cibles privilégiées des attaques du fait de leur grande popularité. Les éditeurs de ces scripts publient régulièrement des correctifs afin d'en combler les failles de sécurité ou d'en corriger des bugs. Malheureusement, certaines de ces failles sont exploitées avant la mise en place de correctifs par des internautes mal intentionnés afin de détourner votre site, et d'y placer des fichiers illégaux ou infectés.

Il est donc essentiel de visiter régulièrement les sites des éditeurs des CMS, extensions, frameworks, bibliothèques Javascript que vous utilisez dans vos pages ; ou de vous abonnez aux flux RSS/newsletters/mailing-lists de sécurité de ceux-ci ou des institutions de veille informatique, comme les CERT.

Liens et ressources utiles

Se protéger du « Spam »

Les formulaires accessibles sans identification (inscription, contact, commentaires, etc.) doivent disposer d'un système de « captcha » limitant les possibilités des robots spammeurs. Si vous utilisez un gestionnaire de contenu, il est fort probable que celui-ci dispose d'un système de protection similaire ou qu'une extension offre cette possibilité d'une manière ou d'une autre. Si vous utilisez vos propres scripts, il est judicieux d'utiliser également des systèmes de protection similaires, même si votre site n'a que peu de visiteurs.

Liens utiles

Filtrer et sécuriser les données envoyées par l'utilisateur

Les injections de code sont les failles les plus répandues sur Internet et les plus dangereuses pour la sécurité de votre script. Les risques que représentent ce genre de faille sont importants car ils peuvent conduire à la divulgation des identifiants des membres, a l'injection de code javascript vérolé ou à la redirection sauvage depuis votre site. Cependant, bloquer les tentatives d'injections SQL est relativement simple, prenez donc la peine de vérifier votre code si vous avez vous-même développé les scripts de vos pages Web.

Liens utiles

Configurer correctement le serveur

Il est important de configurer correctement le serveur car il constitue la première protection de votre site. Ainsi, l'activation de PHP 5, outre le fait d'accélérer le chargement de vos pages, offre une meilleure sécurité par rapport à PHP 4, disponible par défaut sur l'hébergement de Free.

Apache, de son côté, peut offrir également une bonne protection. Vous n'avez sans doute pas besoin que l'ensemble de ces fonctionnalités soient actives. Ainsi, il ne sert à rien d'activer le parsing de fichier PHP si votre site est uniquement constitué de ressources statiques. De même, si vous n'utilisez pas les directives SSI, vous n'avez pas besoin que le serveur contrôle chaque fichier pour vérifier si elles sont présentes ou non avant de l'envoyer au client. De même, le listing de répertoire doit être systématiquement désactivé afin de limiter l'accès des visiteurs de votre site aux seuls documents « liés » entre vos pages.

L'ensemble de cette configuration demande un investissement minime, mais augmentera la sécurité de votre compte de façon significative. Il faut notamment prêter attention aux directives Options.

Le fichier .htaccess minimal (à placer à la racine du compte) pour les pages perso de Free est :

#PHP v5 chez Free
<IfDefine Free>
php 1
</IfDefine>
#Bloquer le listing de répertoire
Options -Indexes

Liens utiles

Se Protéger des iframe et frame

Parmi les méthodes de compromission rencontrées sur l'Internet, il est de plus en plus courant de rencontrer l'insertion de balise iframe dans les codes sources des pages des sites web. Il est donc important de se protéger et de prévenir ce type d'attaque en suivant les recommandations publiées par le CERTA. Il est également possible de se protéger de l'usurpation de son site par l'ajout de l'en-tête X-Frame-Options dans les pages des sites web générées par PHP (il est impossible – sur les pages perso de Free – de préciser cette directive par Apache).

Liens utiles

Interdire l'accès extérieur aux ressources sensibles

Il est important d'interdire l'accès à un certain nombre de ressources sensibles, comme les fichiers de configuration, les données personnelles ou les fichiers indiquant des versions de CMS. Pour ce faire, on utilise les directives Order Allow et Deny. Par exemple, pour interdire l'accès extérieur à un fichier de configuration, on utilisera le groupe de directive suivant :

<Files ~ "config.php">
Order Allow,Deny
Deny from all
</Files>

Liens utiles

Protéger les cookies de site

Les cookies de site sont devenus un rouage essentiel du Web. Il permette d'identifier ou d'authentifier un utilisateur, de le suivre, de personnaliser un site selon l'utilisateur…). Ces petits fichiers textuels sont conservés sur le poste du client. Ils sont à la portée des sites ou des utilisateurs peu srupuleux qui pourraient voler leurs contenus pour se faire passer pour un autre et attaquer ou compromettre un compte. C'est ce que l'on nomme communément le « vol de session ».

Ces vols de cookies peuvent être limités en instruisant le navigateur de les protéger des accès non-autorisés par deux attributs à ajouter à l'en-tête Set-Cookie : HttpOnly (n'est valide que pour des accès par le navigateur) et SameSite (n'est valide que pour communiquer avec le site qui a déposé le cookie).

Set-Cookie: PHPSESSID=8851aba448a5e49f0747d63ffa9027ec; path=/; SameSite; HttpOnly

Utiliser les en-têtes HTTP de sécurité minimale

Il existe des en-têtes HTTP qui permettre d'accroître sensiblement la sécurité de votre site et de vos visiteurs en utilisant quelques en-têtes simples à mettre en œuvre. Vous pouvez les envoyer depuis des scripts PHP, ou via les balises <meta http-equiv="…" content="…"> depuis des pages HTML statiques.

Voici la liste :

X-XSS-Protection: 1; mode=block

Cet en-tête active le mode de protection interne au navigateur contre les attaques par cross-scripting et lui demande de bloquer l'affichage au lieu de tenter d'afficher tout de même la page, expurgée des scripts de l'attaquant.

X-UA-Compatible: IE=Edge

Active le plus haut mode de rendu pour Internet Explorer 8 & 9. Est sans effet sur les autres navigateurs.

X-Frame-Options: SAMEORIGIN

Instruit le navigateur de ne pas afficher la page si celle-ci est contenue dans un cadre sur un site autre que celui dont est issu la page. Cela évite par exemple le clic hijacking ou le vol d'identifiant par un intermédiaire. Les autres valeurs possibles sont DENY ou ALLOW-FROM http://example.net (où http://example.net et le site autorisé à afficher votre site dans un cadre. Cet en-tête n'a aucun effet lorsqu'il est placé dans une balise <meta http-equiv="…" content="…">.

X-Content-Type-Options: nosniff

Évite que les navigateurs tentent de deviner le type de contenu envoyé par le serveur. Essentiel sur les sites où des fichiers sont mis en ligne par un nombre important de personnes, il est également utile sur les autres sites pour se protéger des fichiers vérolés (une image contenant un script javascript caché par exemple).

Referrer-Policy: strict-origin

Il s'agit d'un nouvel en-tête limitant les informations transmises par les liens Referrer des requêtes des clients, dans l'optique de compliquer la surveillance de masse. Les options possibles sont présentées ici. À adapter à votre cas et à vos besoins.

Content-Security-Policy: default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self'; img-src 'self'; font-src 'self';

Cet en-tête permet de définir l'origine des ressources autorisés à être utilisées par le navigateur pour une ressource donnée. Les possibilités étant très nombreuses et la configuration devant être adaptée à chaque site, veuillez lire la documentation avant de l'utiliser, sans quoi votre site pourrait ne plus fonctionner correctement. C'est une arme redoutable contre les attaques de type Cross-Site Scripting.

Limiter l'indexation par les robots

Référencer correctement (interdiction ou autorisation) son site internet est très important, cependant cela peut permettre à des internautes mal intentionnés de découvrir des ressources auxquels ils ne devraient pas avoir accès directement ou repérer des failles de sécurité sur votre site.

Il existe divers moyens simples et performants pour limiter l'indexation de certaines portions ou ressources de votre site : la directive Apache Options -Indexes, l'en-tête X-Robots-Tag (via PHP sur les pages perso de Free) et le fichier robots.txt à la racine de votre compte ou la balise <meta name="robots"…> dans le <head> de vos pages.

Il est important de souligner que ces outils sont inefficaces vis-à-vis des robots et aspirateurs de site ne respectant pas ces directives (si l'utilisateur de tels outils a désactivé manuellement le respect des directives contenues dans le fichier robots.txt). Les sections réellement « sensibles » doivent donc toujours être sécurisées par une authentification du visiteur ou une interdiction d'accès pure et simple.

Un fichier robots.txt ne permet pas de « cacher du contenu » car, étant accessible à tous, il permet de connaitre les URL ou des sections du site qui y sont incluses et de faciliter les tentatives d'accès à vos sections « sensibles ». Il est important de bien concevoir ce fichier et de s'appuyer en complément sur les balises balises <meta name="robots" content="…">, des tags rel="nofollow" ou les en-têtes HTTP X-Robots-Tag. Par ailleurs, les robots malintentionnés passeront le plus souvent outre les directives présentes dans ce fichier.

Liens utiles

Employez les technologies que vous maîtrisez

La méthode la plus simple pour garder son site sécurisé est de n'utiliser que des technologies et des langages de programmation que vous maîtrisez. Il n'y a pas de honte à concevoir et mettre en ligne un site entièrement écrit en langage HTML (surtout avec les derniers développements du HTML5). De même, vous n'avez pas besoin d'utiliser PHP pour de « simples » inclusions de fichiers (comme des menus) ou l'affichage de la liste des fichiers présents dans un dossier, les Server Side Includes sont conçues pour cela, et limitent les risque de failles en raison d'un script PHP mal codé.

Liens utiles

Quelques notions de sécurité pour les pages dynamiques développées par vous-même

Section écrite par Otomatic

Je pars du principe que les développeurs de CMS ont inclus le minimum nécessaire et indispensable pour la sécurité de leur script. Nous nous intéresserons donc à la sécurité minimum des pages dynamiques écrites par soi-même.

Le langage PHP permet de créer des pages dynamiques. L'utilisateur de ces pages peut envoyer ou modifier des informations qui serviront à modifier le site en fonction des paramètres reçus. C'est justement là – réception d'informations – que se situent les principales causes d'attaque de site.

Toujours se rappeler que vous ne maitrisez jamais ce qui est envoyé par l'internaute et que, de plus, les informations envoyées par un utilisateur peuvent être facilement modifiées par un malfaisant.

La principale erreur est de croire que les vérifications ou contraintes appliquées côté utilisateur garantissent la validité des données.

Le Javascript est souvent employé pour contrôler les informations saisies par l'utilisateur avant l'envoi du formulaire et le programmeur pense qu'il n'a pas besoin d'en faire plus. C'est oublier que les vérifications via Javascript peuvent être contournées très facilement en bloquant l'exécution du Javascript au sein du navigateur !

Certains pensent également que l'utilisation de listes déroulantes (balise HTML <select>), checkboxes ou bouton radio, pour forcer le choix de valeurs prédéfinies, les protège de toute attaque. Ils s'affranchissent alors de contrôler et filtrer les données reçues. Ceci est très dangereux.

Des extensions (comme Firebug, pour Firefox) permettent d'éditer le code source d'une page très simplement et ainsi de soumettre des données non prévues.

Et puis, rien n'empêche le malfaisant de créer son propre formulaire – en utilisant les mêmes noms de champs –, et de le faire pointer vers votre page de traitement (avec action). Il est alors libre d'envoyer tout ce qu'il souhaite pour tenter d'exploiter d'hypothétiques failles.

De nombreux sites donnent des exemples très simples de possibilités de récupérer, par exemple, le mot de passe de l'administrateur d'un forum avec la création d'un formulaire, si le programmeur n'a pas pris des précautions élémentaires, dont la primordiale et impérative est :

Il est indispensable de contrôler en PHP, à la réception du formulaire, tous les champs qui le compose (même ceux que l'utilisateur n'a pas à saisir) et qui sont utilisés dans la page. Ces contrôles sont à effectuer avant toute requête SQL ou traitement.

Tout cela pour vous dire qu'il ne faut jamais, jamais, jamais utiliser directement, sans aucun contrôle, les contenus des variables $_GET et $_POST (ou $_REQUEST, qui les combine).

Le strict minimum est de forcer le type pour les valeurs numériques, par exemple :

  • (int)$_POST['page_id'] ou intval($_POST['page_id']) ;
  • (float)$_POST['temp'] ou floatval($_POST['temp']).

ceci évite d'insérer des contenus malfaisants dans une base de données ou dans une URL.

Néanmoins il est très fortement recommandé de vérifier si le contenu de la variable est bien numérique, et si sa valeur est dans les limites de l'utilisation qui va en être faite.

Par exemple, si le formulaire retourne l'âge de l'utilisateur :

if(!is_numeric($_GET['age']) || $_GET['age'] > 1 || $_GET['age'] < 110) {
Traitement de l'erreur
}

Pour les chaînes de caractères, là aussi, il faut vérifier les contenus et, le strict strict minimum à faire, pour insérer la valeur dans une requête SQL, sans avoir vérifié son contenu auparavant, est impérativement d'échapper la variable par (pour MySQL) :

mysql_real_escape_string():
mysql_query("SELECT * FROM USERS WHERE login='".mysql_real_escape_string($_POST['login'])."'
AND password='".mysql_real_escape_string($_POST['password'])."'")

Néanmoins, là aussi, il est très fortement recommandé de vérifier si les contenus sont compatibles avec les informations demandées :

  • Nombre de caractères de chaque chaîne ;
  • Caractères composant les chaînes ;
  • Présence de sous-chaines n'ayant rien à y faire, par exemple : http://.

Pour plus de détails, voir les fonctions de gestion des variables.

Avec l'augmentation du nombre des variables à vérifier, cela peut vite devenir fastidieux et le programmeur aura tendance à « oublier » les vérifications. Le plus simple, en étant partisan du moindre effort, est de créer une fonction multicritères qui va se charger des vérifications.

En voici un exemple simplifié, non exhaustif, à compléter en fonction de vos besoins :

// Fonction de récupération de paramètre $_GET ou $_POST
// $nom     =  Nom du paramètre
// $defaut  =  Valeur par défaut si hors limites
// $type    =  Type du paramètre : entier (int), flottant (flt), texte (txt)
// $lol     =  Limite basse (incluse) pour int ou flt ou longueur minimum pour texte
// $upl     =  Limite haute (incluse) pour int ou flt ou longueur maximum pour texte
function get_param($nom, $type='int', $lol=1, $upl=255, $defaut=false,) {
if (!isset($_REQUEST[$nom])) return false;
else $res=$_REQUEST[$nom];
if ($type=='int' || $type=='flt') {
if (!is_numeric($res)) return $defaut;
if ($type=='int') settype($res,"int");
else settype($res,"float");
if ($res < $lol || $res > $upl) return $defaut;
return $res;
}
elseif ($type=='txt') {
if (!is_string($res) || strlen($res) < $lol || strlen($res) > $upl) return $defaut;
else return $res;
}
else return false;
}

Dans l'exemple précédent de l'âge, cela se traduirait par : $user_age = get_param("age", "int", 1, 110);

Les explications et exemples ci-dessus ne sont pas exhaustifs mais montrent qu'il faut toujours être certain que les données que l'on exploite ont été vérifiées et sont conformes à ce que l'on attend.

Ne jamais utiliser une variable provenant de l'extérieur sans en avoir vérifié le contenu ou la valeur au préalable.

Protection de vos essais

Chez vous, vous développez votre site, vous essayez des « trucs », vous peaufinez vos scripts PHP et, dans certains cas, vous écrivez des petits scripts, juste pour vérifier ou tester une fonction PHP ou MySQL.

Comme il est impossible – même si on peut s'en approcher – d'avoir, en local, le même environnement que chez Free, il arrive un moment où vous êtes bien obligé d'envoyer votre script d'essais sur les pages perso, juste pour voir « si ça marche » chez Free.

Ces bouts de scripts d'essais, vite écrits sans précautions particulières, peuvent contenir des données ou des informations plus ou moins sensibles qu'il ne faut pas mettre à la disposition de n'importe qui qui pourrait accéder — par hasard – au dit script. Il se pourrait également que le dit script fonctionne mal chez Free, se plante en cours d'exécution et révèle ainsi une partie du code.

Il faut donc protéger ces scripts d'essais lorsqu'ils sont « chez Free ».

Une méthode est de regrouper tous les scripts d'essais dans un même dossier, par exemple « tests » et de mettre, dans ce dossier, un fichier .htaccess qui interdira l'accès à tout le monde, sauf à vous, tant en local avec votre serveur de développement, que chez Free pour y effectuer – temporairement – les essais souhaités.

<IfDefine Free>
Order Deny,Allow
Deny from all
Allow from 000.000.000.000
</IfDefine>
<IfDefine !Free>
Order Deny,Allow
Deny from all
Allow from localhost 127.0.0.1 ::1
</IfDefine>

Vous remplacez 000.000.000.000 par l'IP réelle de votre liaison Internet. Ne mettez ::1 que si votre système local supporte IPv6.

En cas d'intrusion, de virus ou de failles

Si vous découvrez des « signes suspects », voici quelques conseils à ne pas oublier et à appliquer le plus rapidement possible :

  1. Sécurisez votre ordinateur en appliquant les mises à jours proposées par les éditeurs de votre système d'exploitation et de vos logiciels. Utilisez une solution de sécurité incluant anti-virus et firewall. Effectuez une analyse anti-virus/anti-malware profonde de votre système et de votre site (en local) ;
  2. Changez et diversifiez vos mots de passe de compte email, accès FTP et SQL (si le compte touché est un compte principal, changez les mots de passe du compte puis, après 4 heures d'attente, de tous les autres comptes secondaires rattachés à celui-ci), il est également important de changer l'ensemble des mots de passe de tous les comptes à votre nom (secondaires ou principaux), disposant ou non de pages perso ; l'intru ayant pu avoir accès à vos autres comptes ;
  3. Bloquez temporairement tous les accès HTTP à votre site par la directive deny from all dans un fichier .htaccess à la racine de votre compte ;
  4. Travaillez sur une copie locale de votre site ;
  5. Mettez à jour vos scripts, CMS et extensions tierces vers les dernières versions stables publiées puis effacer l'ensemble des fichiers et données de l'espace Web et de base SQL avant de déposer votre nouvelle version saine et corrigée.
  6. Vous pouvez rechercher l'origine de la faille et les fichiers modifiés sur votre espace Web à l'aide du script proposé par JC_Et et les développeurs de CMS Made Simple, disponible ⬇︎ ici.

Liens et ressources utiles sur la sécurité des sites web