Accueil > Boîtes à outils > Sécurité et piratage > Le b-a-ba de la sécurité

Le b-a-ba de la sécurité

Chez Ouvaton, nous avons la chance de partager des bouts de disques durs entre nous. C’est sympa, mais ça demande à ce que chacun veille à son niveau à ce que la sécurité collective soit assurée : comme dans un immeuble, on ne laisse pas la porte d’entrée ouverte...

Voici donc un petit memento de la sécurité concernant vos sites, car la sécurité, c’est l’affaire de tous !

Choisir des mots de passe corrects

Choisir un mot de passe correct fait partie des règle de sécurité de base. Le mot de passe identique au login est bien entendu à proscrire. Les dates de naissance, les couples nom-prenom, les mots simples de 4 lettres sont à éviter de manière générale.

Un bon mot de passe doit être constitué au moins de 8 caractères sans logique apparente, mélangeant lettres minuscules et majuscules et chiffres.

On vous propose de composer à partir d’une astuce du genre : "avlcale" est un bon début et pour s’en rappeler "autant va la cruche à l’eau" (du coup faut en trouver un autre ;o)

Je vous laisse deviner avlcale-qtmlb ;o)

Cette remarque concerne aussi bien les accès FTP, que les protections par .htaccess, les accès aux bases de données, les comptes SPIP... elle vous concerne sûrement.

Vérifier les mises à jour des « tout faits »

Lorsque vous utilisez des scripts téléchargés sur le net, votre choix doit être fait minutieusement :

  • choisir un outil suivi et mis à jour régulièrement
  • si possible avec un support actif
  • éviter les projets au point mort (arrêtés)
  • vérifiez que ces scripts sont sécurisés, sans failles de sécurité connues, et avec une maintenance irréprochable, des mises à jours régulières

Nous avons vu à plusieurs reprises des piratages de la plate-forme à cause de scripts téléchargés sur le net et contenant des failles (formail, phpBB). Un guide destiné à vous aider à faire votre choix dans les scripts de gestion de contenu est disponible sur ce site : Choisir son CMS.

Enfin, comme le disait un admin, un site n’est pas une armoire normande qu’on pose dans un coin, mais c’est plutôt une voiture qui mérite énormément d’attention.

Si vous avez donc un site sous SPIP, un blog sous DotClear, qu’il soit petit ou grand, qu’il soit libre ou propriétaire, vérifiez régulièrement les mises à jour de cet outil.

En PHP, ne pas passer de variables sans les vérifier

Lorsque vous passez une variable en argument d’une page à une autre pour l’exploiter en PHP, vérifiez toujours votre variable.

Si vous proposez le choix d’une année, par exemple, que vous passez à la page suivante de la manière suivante :
mapage.php ?annee=2006

Il faudra que la page recevant la variable vérifie cette variable :

$year = GET['annee'] ;
if ( !is_int($year) && $year < 1980 && $year > 2010 )
{
echo "erreur lors de la saisie" ; 
$year = 2005 //valeur par défaut 
}

Les lignes suivantes sont de fait à proscrire :

$fichier = $_GET['file'] ; // récupération de variable
include($fichier . '.php') ; // insertion

Le contenu des formulaires notamment d’envoi de mail sont à vérifier de la même manière et pour les mêmes raisons. Voir cette page à ce propos.

RDV sur les forums si vous souhaitez davantage de précisions ;o)

Les scripts inclus doivent être en *.php

Si vous utilisez souvent un script vous avez intérêt à l’inclure plutôt que de le mettre sur chaque page. Ce peut être le cas de vos identifiants de connexion à votre base de données :

$host = "sql.ou-data.net"; 
$user = "XXXX"; 
$pass = "YYYY"; 
$bdd = "mabase";

dans un fichier connect.php et avoir sur votre site une page du genre :

require("connect.php") ;
// on se connecte à MySQL 
$db = mysql_connect($host, $user, $pass); 
// on séléctionne la base 
mysql_select_db($bdd,$db); 

Si votre fichier est au format .txt, tout le monde peut avoir accès à vos identifiants de connexion, ce qui est foncièrement dangereux pour la plateforme.

Veillez donc à ce que tous vos scripts inclus soient en *.php

Inclure des fichiers externes

Attention GRAND DANGER et à manipuler avec d’infinies précautions
Voir la le lien suivant

Eviter les messages d’erreurs trop explicites

Si vous avez un message d’erreur du type :

there is an error in your sql query in SELECT count(*) FROM mytable where user= and admin=1

Alors l’attaquant peut profiter du fait que vous lui donniez trop d’informations pour corriger et adapter son attaque.

Bref, les messages d’erreur c’est bien ! Mais les messages de débuggage doivent être réservés au développeur et invisibles à l’utilisateur.

Et les scripts faits maison

Moralité : un bon script-maison s’efforce de respecter l’ensemble des critères énoncés ci-dessus.