Page 1 sur 1

[Sessions] Eviter le vol de sessions

Posté : 14 nov. 2006, 01:14
par sylsau
Bonjour,

Je suis en train de mettre en place un site dans lequel j'utilise le mécanisme des sessions pour stocker et passer des variables sur les différentes pages du site.

Pour sécuriser un petit peu plus les sessions, je fais une vérification sur l'IP (Au passage vaut il mieux faire la vérification sur l'IP ou sur le nom d'hôte correspondant à cette IP?) du visiteur tout au long des pages. En cas de différence, je déloggue immédiatement cette personne qui accède à la page.

J'ai lu qu'en utilisant cette vérification sur l'IP, on sécurisait plus les sessions et on atteignait un niveau de sécurité acceptable avec les sessions.

J'aurais donc aimé savoir si vous pensez que cela est suffisant ou s'il fallait rajouter une autre sécurité ?

Merci d'avance de votre aide.

Sylvain

Posté : 14 nov. 2006, 08:12
par momox
Chaque session posséde un id unique que tu peux voir en faisant un session_id() et tu peux grace a ca vérifier que c'est la bonne sessions.
@+

Posté : 14 nov. 2006, 08:39
par Ajoloca
Bonjour,

La majeure partie des internautes n'ont pas d'IP fixe, que feras-tu si elle change entre temps?

A quoi te sert cette précaution si plusieurs personnes se connectent à partir d'une même IP (campus, cyber-cafés, tous ceuX qui sont derrière un PROXY)

Et je crois avoir lu QQ part que certains navigateurs permettent de masquer l'adresse IP.

D'ailleurs je ne suis pas sur que la personne qui arrive à 'voler' des sessions ne soit pas en mesure de transmettre l'adresse IP de son choix (en jouent avec les entêtes, comme pour les sessions).

Posté : 14 nov. 2006, 12:17
par mere-teresa
Tu peux regénérer un nouvel identifiant de session pour rendre invalide l'ancien : si on vole l'identifiant, mais qu'il a changé...on ne peut l'utiliser.

session_regenerate_id()

Cela génère un nouvel identifiant, sans briser le lien entre l'utilisateur et sa session sur le serveur.

Posté : 14 nov. 2006, 12:34
par zigz4g
Dans notre framework, on a inclut une batterie de tests supplémentaires.
On teste l'IP des navigateurs mais c'est seulement pratique dans le cas ou c'est une IP pour une personne physique. On ne peut pas faire confiance à un réseau d'entreprise par exemple.
La majeure partie des internautes n'ont pas d'IP fixe, que feras-tu si elle change entre temps?
Tu peux faire un changement d'identifiant de session en supposant que c'est bien la meme personne mais qu'il est plus prudent de changer l'ID_SESSION.

En plus d'avoir gerer l'ip dans le framework, tu peux faire des tests supplémentaires sur les infos de la machine. De plus, on a incorporer des tests sur du javascript. La on entre dans une verification plus poussée.

Avec tout cela, on passe par une étape en connexion sécurisée (ssl) pour évité que des personnes sur le même réseau que la machine cliente, sniffe sa session.

Après, je vois d'autres solutions mais peut-être limités. Faire une sorte de javascript qui fait une requette vers le serveur pour faire un système de clé publique, clé privé. Mais bon je n'ai pas étudié plus loin la question.

Re: [Sessions] Eviter le vol de sessions

Posté : 18 nov. 2006, 16:54
par Hubert Roksor
vaut il mieux faire la vérification sur l'IP ou sur le nom d'hôte correspondant à cette IP?
IP, le nom d'hôte n'offre aucun garantie supplémentaire et est nettement moins performant (résolution DNS à chaque page).
J'ai lu qu'en utilisant cette vérification sur l'IP, on sécurisait plus les sessions et on atteignait un niveau de sécurité acceptable avec les sessions.
Si tu veux mon avis, le niveau "par défaut" est largement suffisant pour 99,99% des sites. Si ton site n'appartient pas à un domaine particulièrement hostile (site sur la sécurité par exemple, ou sur lequel des transactions financières ont lieu, auquel cas il vaudrait mieux utiliser HTTPS) alors la vérification d'IP n'est qu'un gadget.

Accessoirement, cette pratique pose problème aux utilisateurs se trouvant derrière des proxies tournants (historiquement le cas d'AOL, aujourd'hui je pense que Google Web Accelerator pose le même problème).

Comme le disait mere-teresa, utilise session_regenerate_id() à chaque fois que l'utilisateur se connecte, se déconnecte ou que son accréditation change.