Piratage

Les moyens d'accès pour un pirate sont nombreux. Le plus évident, c'est d'obtenir les mots de passe, soit par "divination" (attaque de force brute, attaque par dictionnaire), soit en les récupérant quelque part (fichier mal protégé, récupération "physique", espionnage de ligne).
Mais il ne faut pas se leurrer, la majorité des piratages viennent de scripts mal sécurisés, laissant des failles ouvertes aux pirates. Que ce soit des scripts personnels (la sécurité ne se pense pas après coup, mais dès les premières étapes de la conception) mal écrits, ou par des débutants, soit des scripts "tout fait" mais pas mis à jour.
La récupération de vos mots de passe par le pirate est alors une conséquence du piratage, pas sa cause.

Le niveau zéro de la sécurité est le choix des mots de passe (secrets donc).
Si le pirate connaît ou trouve vos mots de passe, il fait ce qu'il veut de votre site, y compris changer ses mots de passe !
Mais toute la sécurité ne réside pas que dans les mots de passe : si le pirate trouve un moyen de contourner l'authentification, il n'a même pas besoin du mot de passe ! Quoi qu'il en soit, chaque problème en son temps.

Sans préjuger de failles chez l'hébergeur, ou dans votre PC (keylogger, virus), il est évident que
- si vos mots de passe sont devinables (des mots significatifs, des noms, une date etc...)
- s'ils sont trop courts (donc sensibles à un crackage par force brute)
- s'ils sont écrits en clair quelque part dans votre site lui même
- s'ils sont écrits en clair sur des papiers accessibles aux autres
- si vous les confiez à un tiers, même "de confiance"
- si vous avez le même mot de passe partout
Autant ne pas avoir de mot de passe du tout !

Un bon mot de passe doit donc
- être complètement secret
- être suffisemment long
- être obtenu par tirage aléatoire de signes (lettres majuscules et minuscules, chiffres, signes)

Pour des applications non critiques, le "tirage aléatoire" peut être obtenu mentalement, il suffit de choisir "un peu au hasard" une dizaine de minuscules, majuscules et chiffres, éventuellement d'y glisser un ou deux signes cabalistiques.
Tous les psychologues vous diront que ce tirage mental aléatoire est biaisé.
D'autant plus si la notion de proximité de touches sur un clavier intervient, ou si vous avez choisi un "moyen mnémotechnique".

Un javascript de tirage aléatoire :

Longueur : 6 8 10 12 15 Maj/min       Ol       →
Attention ne pas confondre O majuscule et 0 zéro, l minuscule et 1 un
Les caractères O majuscule et l minuscule peuvent donc être exclus (exclus par défaut)
La liste des caractères spéciaux peut être éditée

Nota : Rappelons que le mot de passe du compte, le mot de passe FTP et le mot de passe SQL peuvent (et devraient) être différents chez Free.
La longueur de ces mots de passe est limitée chez Free.
Et aussi, pour éviter des problèmes de codage de caractères, il est conseillé d'éviter des signes trop "exotiques" qui ne feraient pas partie du code ASCII standard.

Reste un point délicat : ce mot de passe ... passe bien quelque part au moment de l'authentification.
En dehors de transmissions cryptées (https par exemple) il passe donc en clair.
Sans être paranoïaque, ceci est un risque. Inévitable en dehors de protocoles sécurisés.
Pour un site de la défense nationale, ou d'une banque, un protocole sécurisé est donc indispensable (et même tant qu'à faire un réseau totalement isolé).
Pour des pages persos, faut pas exagérer tout de même !
Reste que les mots de passe peuvent être en clair quelque part dans un fichier du site :

Il est donc en clair dans la commande php d'accès à la base SQL : mysql_connect(hostname, username, password);
Bien évidemment cette ligne n'est pas normalement visible, sauf parfois en cas d'erreur !
Une première précaution est de la protéger contre les erreurs par un @, quitte à récupérer les erreurs "à la main" en testant le handle de retour.
En tout état de cause, le mot de passe doit être mis via une variable, et si vous êtes vraiment paranoïaque dans plusieurs variables combinées.
Ah oui, et puis le fichier ou se trouve défini cette variable doit être dans un répertoire inaccessible, sauf en php. C'est à dire dans un répertoire protégé par un .htaccess "deny from all".

Les parties privées du site (administration) doivent être protégées par un mot de passe spécifique, par exemple une authentification http, via le .htaccess et un .htpasswd
Pour des raisons obscures (performances ?), et justifiées à posteriori parce que le codage est facilement crackable, les mots de passe mis dans ce fichier htpasswd doivent être en clair chez Free.
Il est donc indispensable de rendre inaccessible ce fichier .htpasswd, en lui choisissant un autre nom, et surtout en le mettant dans un répertoire protégé par un deny from all.

Les modifications du site (wiki, réponses aux billets d'un blog, commentaires) peuvent être autorisées aux visiteurs. En tout état de cause à certains visiteurs : ceux inscrits au préalable. Ceci passe donc par une authentification, éventuellement en base de donnée par une table des inscrits faisant la correspondance entre l'identité du visiteur et le mot de passe qui lui est demandé.
Il est de bon ton de coder ces mots de passe dans la base de donnée.

Bien évidemment l'administration du site doit être réservée ... à l'administrateur.
Elle doit donc être au minimum protégée par un mot de passe, qu'il vaut mieux choisir différent des autres.
Nota : cacher l'administration sous un nom ésotérique http://monsite.free.fr/f6kmuz/admin.php n'est pas forcément une bonne idée... la sécurité ne doit pas uniquement être due au secret, mais à l'authentification des accès.
Il n'empêche que mettre sur sa page d'accueil un lien "admin" n'est pas une bonne idée non plus : c'est inciter les pirates en leur disant "je vous mets au défi de rentrer là."

La dépose de commentaires, réponses, ou de façon générale tout formulaire est une source d'entrée de code malveillant, autorisant le pirate à prendre le contrôle du site. La plus grande attention doit donc être apportée à la vérification de ces données :
Toute donnée ou paramètre en entrée d'un script php doit donc être soigneusement vérifiée.
Il ne faut jamais supposer que cette donnée vient d'une autre page appelante du site, car elle peut venir directement d'un pirate.

Dans le même ordre d'idée, si vous autorisez tout un chacun à mettre des commentaires, vous vous exposez à ce qu'on dépose du spam sur votre site.
Vous devez vous protéger contre cela :
Au minimum empêcher les robots de déposer des commentaires (captcha),
Au mieux restreindre les commentaires aux visiteurs choisis (= préalablement inscrits)
La parade absolue étant que personne ne puisse mettre de commentaire... mais c'est dommage.
Rappelons à ce sujet que Free tolère 0 spam, à tout instant, visible ou non.
La mise "en attente" de commentaires pour suspicion de spam n'est donc pas tolérée. Si supicion de spam, le commentaire doit être immédiatement détruit sans laisser de trace par le script au moment de sa saisie, au risque d'être un faux positif.

Tout le monde ne programme pas son site "à la main", et bon nombre de sites sont motorisés par des CMS (Content Management System), Forums et Blogs clés en main : SPIP, WordPress, DOTCLEAR, PunBB etc...
Comme pour Windows qui est une cible privilégiée des créateurs de virus, ces CMS de par leur notoriété sont une cible privilégiée des pirates, qui y cherchent en permanence des failles de sécurité. Ces CMS sont donc mis à jour en permanence pour boucher ces failles.
Il vous appartient de répercuter ces mises à jour sur votre site !
Ne pas oublier que les divers "plug in" additionels ne sont pas forcément de la même qualité (sécurité) que le noyau du CMS.
De toute façon ne mettre que les plug in réellement utiles, et les tenir à jour.
Sinon, c'est comme utiliser un Windows sans mise à jour, sans antivirus et sans parefeu... le virus apparaît dans les secondes qui suivent la connexion au réseau.

Peut être avez vous mis des scripts (compteurs, publicités, syndications) faisant inclure dans votre site des morceaux venant d'ailleurs.
Soyez conscient qu'il s'agit d'une faille de sécurité importante.
Même si la sécurité même de votre site n'est pas mise en cause, ceci n'est peut être pas vrai vu du visiteur !
Le site externe pourrait lui offrir une page de phishing, lui proposer du contenu "inaproprié" (illégal ou dangereux) et dans ce cas c'est vous qui seriez directement responsable, puisque vous avez inclus ce contenu dans votre site !
Je ne saurais donc que vous déconseiller l'inclusion intempestive de tout et n'importe quoi sur votre site.
Une inclusion doit être justifiée : apporter quelque chose à votre site, compte tenu de sa thématique.
Quel intérêt de proposer une page météo dans un site de musique ?
Quel intérêt de savoir (à part pour vous) le nombre de visiteurs de la page ?
Quel intérêt d'inclure des publicités dans une page perso ?

Le risque zéro n'existant pas, comment réagir si, malgré toutes les précautions prises, le site a été piraté ?
Et déjà comment s'en apercevoir...
En dehors des cas manifestes (plaintes, blocage par Free, défaçage) il n'y a qu'une seule méthode : surveiller régulièrement le contenu de votre site, le comparer à votre sauvegarde locale (vous avez bien une sauvegarde locale, n'est-ce pas ?)

La première chose à faire est de bloquer tout accès par le pirate, et tout danger pour les visiteurs :
Si le site n'est pas déja bloqué, le bloquer volontairement par un htacces. Ceci empêchera le pirate d'accèder aux backdoors qu'il a pu laisser dans votre site, et aux visiteurs de se faire avoir.
Changer tous vos mots de passe.
Demander le déblocage de l'accès FTP au besoin. (la demande doit être argumentée : quelle est la cause du blocage, la faille probable, ce que vous avez deja fait, ce que vous comptez faire. Ne donner que l'aspect technique, sans considérations émotionnelles)

Nettoyer et mettre à jour, interroger les annonces de mise à jour et les forums des CMS utilisés, regarder partout, comparer les dates et tailles des fichiers, restituer les fichiers sauvegardés, etc.
Autoriser l'accès http pour vous seul (à votre seule IP par exemple) pour modifier ce qui doit être fait par php (admin).
Enfin, maintenant que tout est clean et que vous avez identifié et colmaté les brèches utilisables/utilisées par le pirate (et pas seulement supprimé les fichiers malveillants qu'il avait déposé), vous pouvez enfin réouvrir le site au public.

Bien entendu qu'on ne vous y reprenne plus : tenez vous en permanence au courant des failles de sécurité de vos CMS, et mettez à jour. Tout le temps. Webmaster, même amateur, c'est un vrai boulot !