23. Sécuriser les accès à un site Internet en PHP.

1. Les cookies - 2. Les codes de sessions - 3. Des solutions presque parfaites - 4. Programmer un mot de passe aléatoire - 5. Pour conclure

Une large partie des sites en PHP doivent permettre de suivre des utilisateurs (enregistrés et connectés principalement mais pas forcément). Diverses programmes utilisés sur les sites Internet nécessitent de différencier les utilisateurs: compteurs de visites et statistiques diverses (même si une solution externe gratuite ou payante est souvent préférable), suivi d'utilisateurs inscrits, panier dans les solutions de vente en ligne, ... Nous allons expliquer les méthodes à utiliser (les très bonnes, les autres et les pas bonnes du tout). La distinction entre deux visiteurs différents peut se faire soit par:

l'adresse IP du visiteur qui est très facile à récupérer en PHP mais impossible de distinguer plusieurs visiteurs provenant d'une même connexion interne via un routeur (sans compter les serveurs proxy). L'adresse IP permet (en gros) de déterminer le pays de provenance de la connexion et d'autres paramètres. Vous pouvez coupler cette solution avec l'une des deux suivantes.
de petits fichiers textes appelés cookies insérés sur l'ordinateur du visiteur (donc unique par visiteur) et lus par le serveur Interne. Cette solution est donc nettement plus intéressante. Par contre, l'utilisateur peut interdire les cookies sur son ordinateur et reste à faire la liaison entre l'utilisateur et son nom d'utilisateur.
un paramètre de session passé créé automatiquement par le serveur qui peut être passé par l'URL (déconseillé pour le référencement) ou en utilisant une table de session.
un système software combiné avec un lecteur de carte qui authentifie l'utilisateur: utilisé par exemple par les transactions avec cartes d'identité belges mais pas pour les transactions bancaires.
Les accès au comptes en banque utilisent une authentification numéro de carte - code de la carte mais avec une suite préprogrammée de numéros.
Les achats en ligne par carte de crédit renvoient au moment du payement vers des sites qui utilisent d'autres méthodes (mais toujours liés au numéro de carte et au code) utilisant l'adresse IP et des méthodes de cryptage plus ou moins évolués et un découpage de la transaction avec chaque fois une nouvelle vérification. Par contre, les législations en vigueur dans le monde ne permettent pas d'associer une carte de crédit à une adresse (ce qui bloquerait une partie des vols). Ce qui est étonnant, pour la Belgique et d'autres pays (bientôt en France), n'importe quel fonctionnaire de l'état à l'accès via la carte d'identité électronique et la base de donnée associée aux comptes en banque, dossier médicaux, emprunts, utilisation des différentes cartes bancaires dans les magasins, ... de n'importe quel citoyen: cherchez l'erreur.

Dans la suite, nous ne verrons que les trois premières méthodes, les autres sont réservées à des experts de la sécurité et de la programmation qui ont d'autres méthodes et moyens.

1. Gestion par cookies

Cette méthode est acceptée par tous les navigateurs actuels mais peut être refusée par configuration. Ce qui peut poser problèmes, c'est le contenu du (des) fichier(s) transféré sur l'ordinateur du visiteur. Dans le cas d'un suivi utilisateur (statistiques de visites), c'est un simple numéro qui correspond à une entrée dans une table MySQL. Aucune vérification de l'utilisateur n'est nécessaire. Par contre, dans le cas d'une authentification sur un site, différentes solutions sont possibles:

le nom d'utilisateur et son mot de passe: comme le contenu d'un cookie peut facilement être lu par un utilisateur mais aussi par un programme parasite implanté sur l'ordinateur.
idem mais en cryptant le mot de passe. Un peu plus sécurisée, mais même difficilement il est toujours possible de le décrypter. En pratique, surtout si le webmaster impose un mot de passe, cette solution est suffisamment sécurisée.
un numéro aléatoire en correspondance avec un enregistrement dans une table qui elle reprend le nom et le mot de passe. Cette solution utilise un principe équivalent aux ID de sessions.

Pour la déconnexion, les deux premières solutions passent simplement par supprimer le fichier sur le PC du visiteur, la troisième supprime simplement l'entrée correspondante dans la table. Petits problèmes possibles, Internet Explorer 8 gère ces fichiers différemment de tous les autres navigateurs (pas les versions inférieures) avec des connexions impossibles et des déconnexions aléatoires.

2. Les paramètres de session.

Chaque visiteur reçoit automatiquement un numéro de session dès qu'il lit une page du site. Ce numéro unique est créé par le serveur et suit chaque visiteur de page en page, c'est automatique. La technique est d'ajouter des paramètres pour l'utilisateur connecté (ses codes d'identification) et de les supprimer quand l'utilisateur se déconnecte. Ces ID de session ont une durée de vie de quelques dizaines de minutes, paramétrable dans PHP.ini du serveur apache avec la clé session.gc_maxlifetime. Ils doivent être régulièrement régénérés. Cette solution peut sembler la plus sécurisée puisque rien n'est transmis sur l'ordinateur du visiteur. Pourtant, elle a plusieurs défauts. Si l'utilisateur quitte le site, la session reste ouverte et un simple numéro aléatoire (que peut créer un simple programme qui analyse toutes les combinaisons possibles) permet d'utiliser une session légitime quelques instants. Par contre, si l'utilisateur se déconnecte, la session est supprimée. On parle de vol de session. En deuxième, les robots et programmes de piratages, copieurs de sites, ... vont AUSSI se faire attribuer un ID de session. C'est ici le petit problème de sécurité. Par compte, les robots n'acceptent pas les ... cookies.

3. Des solutions presque parfaites.

En relisant la gestion des cookies, on retrouve aussi l'utilisation d'un numéro aléatoire et ... les ID de sessions sont justement des numéros aléatoires. En même temps, les cookies ne sont pas acceptés par les robots et autres. Voici déjà une première solution: utiliser les cookies en utilisant le numéro aléatoire créé par l'ID de session comme numéro, l'envoyer en cookie et ... gérer une table qui met en correspondance ce numéro avec des codes et droits d'accès. Sans accepter les cookies, impossible de se connecter et si l'utilisateur n'est pas connecté, la table ne reprend strictement que le numéro. Au niveau du PC client, un simple cookie contenant un numéro. En se déconnectant, l'ID reste en fonction mais plus d'accès.

L'adresse IP va aussi renforcer le mécanisme. En insérant dans le cookie et dans la table de suivi l'adresse IP du visiteur, on va limiter l'utilisation de la session à ... une adresse. Ca va permettre aussi de bloquer des plages d'adresses IP jugées dangereuses (beaucoup de sites de petites annonces bloquent certains pays sensibles).

Et l'HTTPS? A part utiliser le port 443 au lieu du 80, c'est quoi la différence avec une simple connexion HTTP? En 'S, la communication est cryptée suivant une clé fournie par le serveur au départ. Cette méthode de transmission va simplement empêcher des programmes d'analyser le contenu de la transmission (on appelle ces logiciels des sniffers). Ne rêvons pas, cette solution n'est guère plus sécurisée que la méthode standard.

Et pourtant ... la majorité des utilisateurs gardent les connexions en automatique pour se reconnecter automatiquement. L'accès au PC donne l'accès aux sites, ou même le navigateur enregistre le mot de passe: une fois le nom d'utilisateur entré, le mot de passe se met automatiquement. Et devinez quel type de programme est capable d'utiliser ces fonctionnalités: les trojans. Blinder la sécurité des accès aux sites ne garantit pas une sécurité maximale.

4. Créer un mot de passe aléatoire

Dans la majorité des sites ou vous vous inscrivez, c'est vous, utilisateur, qui choisissez le mot de passe. Pour le site, ce n'est pas forcément une solution idéale de sécurité. Ici nous allons imposer le mot de passe. En complément, les stratégies de mots de passe ... dans la partie sécurité Internet.

Nous allons simplement créer un mot de passe aléatoire de 10 caractères (lettres en majuscule et minuscule et chiffres) qui sera envoyé à l'utilisateur enregistré par mail et repris dans la table utilisateur.

$char = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890';
$password = '';

for($i=0;$i < 10;$i++) //10 est le nombre de caractères
{
$password .= substr($char,rand()%(strlen($char)),1);
}
echo $password;

On commence par assigner la variable $char à une suite de lettres, toutes les minuscules suivies de toutes les majuscules de l'alphabet, suivi des 10 chiffres. La variable $password est déclarée au préalable (à vide). La suite utilise une boucle for qui débute à la valeur $i=0, incrémentée de 1 à chaque passage tant qu'elle n'égale pas 10 (le nombre de caractères du mot de passe). A chaque passage, le programme concatène la variable $password (.= ) avec 1 caractère: substr (variable,numero,1) . Comme variable, on utilise $char qui reprend l'ensemble des caractères possibles et comme numéro de caractère rand() - sans paramètres qui fournit une valeur aléatoire comprise entre 1 et 32768 - %(strlen($char)) est un nombre compris entre 1 et 62 - % signifie modulo. Le mot de passe sera chaque fois différent avec 62¹⁰ valeurs possibles.

5. Pour terminer

La grosse majorité des attaques de sites Internet ne se fait pas en piratant un compte (à part celui d'administrateur) mais en injectant des codes MySQL dans les formulaires (attaques par injection MySQL), en utilisant des failles du système d'exploitation ou dans la programmation des ... développements. Par expérience, les développements personnels sont nettement moins soumis aux attaques que les CMS, forums et autres logiciels de vente installés automatiquement: ces tentatives de piratage sont faites en automatique et c'est nettement plus facile de les exécuter sur des applications connues que sur des petits développements personnels: le POO semble aussi plus facile à passer que les solutions manuelles, probablement parce qu'elles sont plus automatisées au niveau des lignes de commandes. On a déjà vu que toutes les paramètres entrés dans un formulaire doivent être récupérés via une fonction addslashes, c'est juste un minimum.

Nous n'a pas encore parlé réellement de cryptage des données. Pourtant, une base de donnée peut aussi être "piratée", les mots de passe dans la table des utilisateurs doivent aussi crypté. Des fichiers htaccess doivent être intégrés dans chaque dossier de fonction pour restreindre l'utilisation au nom de domaine.

Depuis le début de cette formation, nous nous sommes plutôt amusés à programmer (apprendre des bases) sans trop se compliquer la vie. Nous allons dans la suite commencer à s'occuper de professionnaliser nos programmes. Différents chapitres vont reprendre les cookies, ID de session, cryptage, ... pas à pas en plusieurs étapes.

Autre sécurité d'un site Internet, minimiser les tentatives d'injection SQL, aspirateurs de sites et autres

> 24. Exercice, gestion de communiqués et news

<22 . Développement: Filtrage d'annonces

Mis en ligne le 24/04/2012. Inséré avant l'utilisation des cookies