Discussion :

[psychoBob]

Bonjour,
Je lis le post épinglé sous le nom " [Login membre] Sécurité TOTALE !!!" et Maxou d'y écrire :

si tu veux un petit plus pour la sécurité, enregistre dans ta session, l'adresse IP ou la signature du navigateur (ou les deux ) et tu auras un meilleur niveau de sécurité

ensuite tu peux aussi modifier le nom de cookie de session mais ce renseignement s'obtient rien qu'en se connectant donc ce n'est pas indispensable

Alors je voudrais que l'on m'explique en quoi l'enregistrement de l'adresse IP de celui qui vient de s'identifier permet d'avoir un meilleur niveau de sécurité.
Parce que c'est la première fois que je travaille avec les sessions et je suis en train de peaufiner mon premier espace membre.


Merci de m'éclairer sur ce sujet s'il vous plait.

[MasterOfChakhaL]

je pense que ca peut te prémunir du "vol de cookie"

en effet, une solution pour gérer les espace membre est de placer chez ton utilisateur un cookie qui contient l'id de session qui peu être généré en php en utilisant la fonction session_start()...

en vérifiant la correspondance entre id de session et ip tu fermes une des nombreuses failles possibles...

Je ne suis pas un pro de la sécurité mais c'est comme ca que je l'avais compris.

Je laisse la place aux experts...

[psychoBob]

Oui mais j'en fais quoi de l'IP dans la session ? Je la récupère et je l'envoie dans la base juste après l'inscription puis je compare au fur et à mesure id et IP, chaque fois que l'utilisateur identifié poste un truc ?

[billoum]

Salut,

comme les ip changent régulièrement, tu ne dois pas l'enregistrer lors de l'inscription. Il faut que tu enregistres, dans une variable de session, l'ip de l'utilisateur qui s'est authentifié . Puis tu la compares à l'ip de celui qui a demandé la page.

a+

[psychoBob]

Salut Billoum,

Ce que je ne comprend pas c'est quand tu dis "Puis tu la compares à l'ip de celui qui a demandé la page".

Je résume :
Le gars s'identifie.
J'attrape son IP et je l'envoie en session.
Mais maintenant, à quel moment je la compare ? Quand il demande une page à acces conditionnel, comme par exemple une page de formulaire de participation au forum ?

[chaced]

je pense que ca peut te prémunir du "vol de cookie"

en effet, une solution pour gérer les espace membre est de placer chez ton utilisateur un cookie qui contient l'id de session qui peu être généré en php en utilisant la fonction session_start()...

en vérifiant la correspondance entre id de session et ip tu fermes une des nombreuses failles possibles...

Je ne suis pas un pro de la sécurité mais c'est comme ca que je l'avais compris.

Je laisse la place aux experts...

Et si le connécté provient d'aol et qui change d'ip 40 fois en quelques secondes ? (chez aol, ils passent par des proxy)

[Yogui]

Salut

Cette technique est utile principalement dans le cas où l'identifiant de session est passé dans l'URL.

Il m'est arrivé un truc fun, une fois : un pote m'a filé un lien vers un article sur une boutique en ligne. J'ai cliqué et j'ai vu des articles qui m'intéressaient. J'ai donc fait mes courses, puis j'ai commandé et validé.
Au final, nous avons tous les deux reçu la même commande...
En fait, il avait lui aussi un panier quand il m'a donné le lien. Il y avait l'ID de session dans le lien et le site ne vérifiait pas l'IP. Conséquence : nous avons fait nos courses avec le même panier virtuel, sans nous en rendre compte...

[psychoBob]

Deux témoignages intéressants mais qui n'éclairent point ma lanterne outre mesure.

En pratique, je fais ainsi (pour le moment) :

- Le visiteur s'identifie.
- Avec ses informations de connexions je récupère l'identifiant de son compte.
- Je n'affiche les pages à accès réservés que si la variable de session contenant l'identifiant d'un compte est présente.
- J'affiche les informations concernant ce membre en allant chercher dans la table les données correspondant à son identifiant.

Maintenant je peux aussi récupérer son ip lors de l'identification, l'expédier dans la table membre sous le tuple "dernière connexion", puis comparer au fil des pages si celui qui demande l'accès à une page a bien l'id initiale ET l'ip enregistrée lors de l'identification.

J'ai bon ? Ou je me ramasse lamentablement en frottant sur les dents de devant ?


(l'identifiant de session est masqué dans l'url).

[Fladnag]

Enregistrer l'IP dans la session ne sert pas a verifier l'utilisation *d'une fois sur l'autre* mais plutot *entre chaque page* (de la meme session)

En gros, si tu as une session, c'est pour transmettre des variables d'une page a l'autre grace a elle.
Donc chaque fois que tu fait un session_start() tu peux récuperer l'IP que tu as stocké dans la session et la comparer a l'IP de l'internaute qui charge la page... si l'IP est différente, c'est soit un vol de cookie soit un gars qui passe derriere des proxys styles AOL...

[psychoBob]

Donc chaque fois que tu fait un session_start() tu peux récuperer l'IP que tu as stocké dans la session et la comparer a l'IP de l'internaute qui charge la page

Ok là j'ai compris.

Mais alors pour chaque page, je dois faire une structure conditionnelle : si c'est bon on affiche la page, sinon un message d'erreur ?
Ne peut-on le faire que pour certaines pages, telles que celles permettant de changer les informations du membre ?
Et que faire pour les gens d'aol ?

[billoum]

²J'ai oublié de te le donner hier mais ya un tutoriel la-dessus sur dveloppez.

En particulier ce qui t'intéresse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
<?php 
session_start(); 
 
if(!isset($_SESSION['last_access']) || !isset($_SESSION['ipaddr']) || !isset($_S [IMG]http://bob.developpez.com/phpauth/images/ciseaux.png[/IMG]
ESSION['user'])) 
{ 
  $_SESSION=array(); 
  session_destroy();  
  header("Location: login.php"); 
  die(); 
} 
 
if(time()-$_SESSION['last_access']>$session_timeout) 
{ 
  $_SESSION=array(); 
  session_destroy(); 
  header("Location: login.php"); 
  die(); 
} 
if($_SERVER['REMOTE_ADDR']!=$_SESSION['ipaddr']) 
{ 
  $_SESSION=array(); 
  session_destroy();  
  header("Location: login.php"); 
  die(); 
} 
$_SESSION['last_access']=time(); 
?>

Puis tu places ce code en début de chaque page que tu veux protéger (tu choisis lesquelles)

Quant aux clients d'aol ben jsais pas trop (à part changer de provider)

[Fladnag]

oui, tu dois le faire pour chaque page, maintenant si ton site est bien concu, tu dois avoir un fichier php appelé en haut de chaque page qui sert a faire différente initialisation (comme le session_start())

faire un if( ...) ne demande pas beaucoup de ressources ;o)

Oui, tu peux faire ca uniquement sur les pages *sensibles*, mais je vois pas l'interet

Pour les AOLiens... ben y a pas vraiment de solution ;o)
Si tu arrive a les detecter tu peux desactiver le test (par exemple en filtrant sur les plages IP utilisée par AOL, mais ca peut changer, ou encore en faisant un gethostbyaddr(), mais c'est *tres* long comme fonction (1 ou 2 secondes environ))
Sans parler du fait qu'AOL est cité a titre d'exemple, mais il y a des milliers d'autres cas... certains proxys d'entreprise pour en citer un autre.

Quand a l'action a entreprendre si l'IP est différente, elle est simple : changer l'ID de session avec session_regenerate_id() puis déconnecter l'utilisation (en affichant un formulaire de login/pass)

Tu peux aussi laisser a l'utilisateur le choix d'utiliser cette sécurité.
Par exemple, lorsque tu detecte un cas d'IP différent, tu affiche un formulaire de login avec un message : "Si vous avez été déconnecté a tort, veuillez cocher cette case avant de vous relogger", et tu enregistre la case dans la base de donnée comme un booleen qui désactive le test de l'IP

[psychoBob]

Ok, merci pour vos réponses, je vais plancher sur les sessions (je ne les ai encore jamais utilisé). Merci Billoum pour le lien.

Si je vous suis bien, les utilisateurs d'aol ou ceux qui se connectent par des proxys, je fais une croix dessus si je veux bien sécuriser mon site ?

(c'est très très fréquent ce vol de session ? )

[wamania]

un solution que je préfère, c'est de générer un id session et un id_session_page
Le premier se génére au début de la session et reste tout au long de la session, le deuxième est regénéré à chaque page.
C'est le meme principe que le test de l'IP, sans les inconvénients lié à l'IP

[billoum]

un solution que je préfère, c'est de générer un id session et un id_session_page

Le problème c'est qu'on utilise le test de l'ip justement parce que le vol de l'id de session est assez facile (enfin c ce que j'ai cru comprendre).

[psychoBob]

Vous pensez quoi de ça, les autres ? ça règle le problème des proxys et des connectés via aol, non ?

Mais Wamania, si tu génères un id-session et un id_session_page (j'ignore la différence entre les deux, du reste), ils ne vont pas être identiques, comment les comparer, alors ?

(Y'a du boulot sur les sessions en perspective, si je veux faire du bon travail, je crois.)

[psychoBob]

Le problème c'est qu'on utilise le test de l'ip justement parce que le vol de l'id de session est assez facile (enfin c ce que j'ai cru comprendre).

Ah oui finalement, le pirate vol les deux et puis c'est tout, c'est ça ?

[wamania]

le vol de session est possible si tu n'as que 1 id pour la session, on récupère cet id et ça roule
mais si un 2eme id change à chaque page, le vol de session est impossible.

[billoum]

Et si un pirate vole les 2 id et puis qu'il demande une page avant que l'utilisateur n'en charge une autre, là il pourra qd même voler la session ?

[wamania]

pour clarifier, un exemple
un gars se connecte
session_id : 2745
session_id_page : 2135
(bien sur les id doivent etre plus long)

page suivante
session_id : 2745
session_id_page : 8634

...
le session_id_page est stocké chez le client (url, cookie..) ET sur le serveur comme le session_id
aisni, à chaque page, on vérifie si session_id client et serveur sont égaux et idem pour session_id_page

si un gars pique la session, un appelle à une page va renouveller le session_id_page, donc
- le hacker a le nouvel id
- l'autre a l'ancien

un seul appel d'une page par l'autre déconnectera les deux, car son session_id_page n'est plus valide, et qu'ils utilisent tous les 2 le meme session_id

De plus, il faut que le hacker ai le temps le piqué les 2 variables et les utilise avant que l'utilisateur ne r'appelle une autre page, sinon le session_id_page sera obselete, et il lui faudra le recapturer à nouveau.

le soucis intervient si le hacker pique la session pil poil au moment ou le gars s'arrete de navigué.
-> d'ou la nécessité de se déconnecter proprement

Voila en gros l'explication