Tutoriel récapitulatif de sécurité (PHP5)

Dans vos scripts, il est fondamental d'aborder certains aspects avec le plus de précautions qu'il vous soit possible. Il ne s'agit pas d'empêcher un piratage mais plutôt de tellement baisser la probabilité de réussite que le pirate abandonnera avant d'y parvenir.
Par exemple, supposons d'un côté qu'il faut un temps moyen de deux ans à un ordinateur de la dernière génération pour décoder un mot de passe chiffré avec tel algorithme ; de l'autre, supposons que votre politique de sécurité contraigne vos utilisateurs à changer de mot de passe tous les deux mois ; il est alors raisonnable de penser qu'un pirate aura très peu de chances de parvenir à décoder un mot de passe dans la fenêtre de temps qui lui est impartie.
La sécurité, c'est cela : donner à des informations sensibles une durée de vie inférieure au temps que le pirate mettra à les déchiffrer, de telle manière qu'elles deviendront inutiles au pirate quand il y parviendra (car il y parviendra).

C'est la question qui revient le plus souvent : "comment sécuriser mon espace membre ?"
Comme souvent, il est possible de mettre en place divers mécanismes, seuls ou bien combinés. Plus on ajoute de mécanismes, plus l'espace membre sera sécurisé. Attention : cela implique également que l'utilisateur ait davantage de contraintes.

C'est non seulement la technique la plus simple à mettre en place, mais aussi celle qui est rendue obligatoire par la loi française.
Lors de l'enregistrement d'un membre, son mot de passe est encodé à l'aide d'une fonction de hashage, c'est-à-dire une fonction qui encode un texte de telle manière qu'il soit impossible de retrouver le texte d'origine. Lors de chaque connexion du membre, il envoie son véritable mot de passe, puis nous comparons le hash de cette chaîne avec le hash que nous avons enregistré dans notre base de données.
Cette technique est satisfaisante pour parer les intrusions simples. Cependant, un utilisateur expérimenté peut écouter la communication entre un client et le serveur et, ainsi, récupérer le mot de passe avant que le serveur en calcule le hash. Afin d'y pallier, nous pouvons mettre en place un encodage supplémentaire du côté du client, c'est-à-dire par le navigateur Web. Ainsi, le client encode son mot de passe avant de l'envoyer au serveur, puis le serveur l'encode à nouveau avant de l'enregistrer dans la base de données. Lors de la connexion du visiteur au site, il faut procéder de la même manière : encodage du mot de passe avant d'initier la communication HTTP, puis nouvel encodage avant de comparer avec le contenu de la base de données. Attention : ce n'est pas le fait que le mot de passe soit doublement encodé qui assure une meilleure sécurité ; c'est plutôt le fait que le mot de passe soit encodé par tous les intermédiaires de la communication (les acteurs étant : l'utilisateur, son navigateur, le serveur, le serveur de bases de données).

Maintenant que l'utilisateur est enregistré dans son espace membre, il ne souhaite pas à avoir à saisir son nom d'utilisateur et son login à chaque fois qu'il vient sur le site. Il veut que son navigateur le connecte automatiquement. Après tout, il est la même personne chaque jour de sa vie...
Ici, nous allons mettre en place une solution à base de cookies. Les cookies sont des fichiers enregistrés par le navigateur, à la demande du site Web. Ils sont donc situés sur l'ordinateur de l'internaute et, a priori, ils sont disponibles d'une visite à l'autre. Cependant, puisqu'ils sont situés sur le disque dur de notre visiteur, ils sont susceptibles d'être modifiés sans que le site en ait connaissance. Il faut donc conserver uniquement des données dont personne, à part notre site, ne peut deviner le fonctionnement exact. De cette manière, nous pouvons supposer que le cookie contient des informations relativement fiables ou, dans le pire des cas, simplement inutiles.
Par exemple, une technique consiste à générer un nouvel identifiant de session à chaque fois qu'un utilisateur se connecte au site. Cet identifiant est utilisé tout au long de la session. Nous l'enregistrons dans la table de la base de données qui contient les informations du profil membre. Nous l'envoyons également au cookie : il fera partie des identifiants que nous utiliserons. Lors de chaque nouvelle visite sur le site, nous attribuons à l'utilisateur un nouvel identifiant de session à enregistrer dans le cookie.

Bien sûr, ce n'est pas une mesure suffisante. Il convient d'ajouter aux informations envoyées par le cookie autant d'informations que possible : nom d'utilisateur, dernière adresse IP utilisée lors d'une session sur notre site, date de la dernière connexion au site, etc. L'important ici est d'ajouter des informations qu'il est difficile d'obtenir depuis l'extérieur, qu'il est difficile de falsifier et qui sont aussi uniques que possible.

Tout site propose un lien de déconnexion pour terminer une session (et supprimer les cookies du client). Cependant, peu d'utilisateurs utilisent systématiquement ce moyen pour terminer leur session. Beaucoup ferment simplement le navigateur ou bien le laissent ouvert toute la nuit (moi le premier). Pour être honnête, il m'arrive de laisser mon navigateur ouvert plusieurs jours de suite. Si un site sur lequel je suis connecté n'a pas mis en place de système pour terminer automatiquement ma session au bout d'un certain temps, alors il est possible que ma session reste active très, trèèèès longtemps. Et ça, du point de vue de la sécurité, ce n'est pas bon du tout ! Cela facilite le vol de session par un intrus en lui donnant une fenêtre de temps très large pour me voler ma session.
De plus, au bout d'un temps, le serveur serait surchargé par des variables de session qui sont inactives depuis longtemps et qui n'ont probablement plus de raison d'exister.
Il faut donc faire une vérification périodique de l'activité d'une session. Par exemple, si un utilisateur n'a pas été actif sur le site pendant au moins une heure, alors nous le déconnectons puis nous reprenons à partir du processus de connexion. Peut-être a-t-il demandé la connexion automatique, auquel cas tout cela sera transparent pour lui. Il ne s'en rendra pas compte, mais nous lui avons attribué un nouvel identifiant de sesson, nous lui avons mis à jour ses cookies, etc.