Bonjour,
je m'intéresse épisodiquement à la programmation depuis quelques années, ce qui m'a servi à écrire divers petits utilitaires à but personnel.
Je me suis intéressé il y a assez longtemps aux sessions (lorsqu'elles ont été incorporées à PHP), et j'ai donc créé une petite classe perso (probablement pas géniale mais bon) de sessions (sans utiliser les fonctions session de PhP).
J'utilisais donc un identifiant de session, qu'il fallait propager via les cookies, et je conservais les données dans une table SQL dédiée aux sessions, avec un certain nombre de précautions visant à avoir une bonne sécurité.
Il se fait que je reprend maintenant mes vieux bouts de code, et je lis la littérature sur le sujet, et je découvre avec intérêt un système de session qui dépendrait désormais essentiellement des cookies, et qui ne nécessiterait plus du tout de table SQL dédiée aux sessions.
Si quelqu'un est curieux je peux développer un peu le sujet, mais mes problèmes sont les suivants :
Le gros soucis théorique qui me bloque dans l'implémentation de cette méthode, c'est que je perd une protection que j'aimais bien contre l'hijacking de session.
En résumé, si un pirate arrive à sniffer le cookie et copier son contenu, il possède une session valide.
Auparavant, je gérais ce cas en stockant le nombre de visites effectuées pendant la session, et en l'incrémentant automatiquement dans le cookie. Ce qui fait que si un internaute surfe et se fait sniffer sa session, le pirate ne peut l'utiliser que lorsque l'internaute arrête de surfer, car sinon je détecte facilement que le nombre de visites ne correspond pas (je reçois deux fois un cookie qui déclare que l'internaute X a déjà fait 10 visites, info que je stocke aussi dans la BDD).
Et je ne vois absolument pas comment détecter deux sessions qui se chevauchent sans utiliser une technique qui implique SQL (ce qui tue l'un des avantages des sessions qui se basent uniquement sur les cookies).
Enfin bref, la meilleure technique que je trouve actuellement, c'est d'enregistrer les log (ce que je fais de toute façon) dans une table SQL, qui est analysée et nettoyée tous les mois (ou plus fréquemment si ya du passage), et d'inclure dans les logs le couple (user_id . timestamp de la session), et d'imposer qu'il soit unique.
Donc si un internaute essaye d'utiliser un cookie qui a déjà été utilisé, je ne vais pas pouvoir l'inclure dans les logs (erreur SQL j'imagine), et je saurai qu'il y a éventuellement tentative d'hijacking.
=> Une erreur SQL sur une insertion dans une table pour cause de non-unicité d'un des champs est une solution élégante ou non puisqu'elle dépend d'une erreur ?
=> Un internaute qui "clique trop vite" ne va-t-il pas générer cette erreur ?
Si je permet deux clicks dans un intervalle très court (pour gérer ce comportement), c'est laisser une fenêtre ouverte à un hijackeur qui sait "cliquer" en même temps plus ou moins que sa victime (et je sais pas si c'est possible, ou si je suis parano ^^).
Une autre méthode que j'utilisais aussi, c'est enregistrer l'user-agent de l'internaute, car il n'est pas censé changer. Mais quelqu'un capable de sniffer un cookie est à mon avis complètement capable de copier l'user-agent ...
Donc utiliser l'user-agent comme élément de sécurité n'a d'intérêt que contre les voleurs de cookies qui ne savent pas se procurer l'user-agent de leur victime (ça existe?).
Merci de m'éclairer, et désolé si je suis un peu brouillon dans mes explications.
Partager