(07-12-2008, 11:21 AM)Anthor a écrit : C'est pourtant une solution reconnu dans le monde du développement. Peut-être devrait-tu revoir le fonctionnement interne des sessions ?Je dois pas avoir grand chose à ce que tu me dis je pense (ou alors on parle pas de la même chose) ^^'
Si tu change de navigateur, le premier est automatiquement déconnecté, grâce au changement d'id, puis du vidage, qui reconnecte une nouvelle session. L'ordre est important, car si tu vides en premier, l'identifiant reste le même.Le pirate ne peux plus réouvrir la session à moins de retrouver l'identifiant de session.
Enfin, tu devrais savoir que cela fait parti des préconisations de Zend en matière de sécurité. M'enfin je dit ça je dit rien... Continuez donc à vous réinventer la roue avec des script inutiles et coûteux en ressources ^^
Soyons précis, parce que c'est un peu brouillon.
Moi ce que je disais c'est:
Tu es connecté sous "pseudo A" sur Internet Explorer.
Tu décides de te connecter dans le même temps sur mozilla avec ce même compte.
Tu auras donc 2 sessions sur un seul et même compte.
Donc deux identifiants de session pour un seul utilisateur.
Si tu parles de la même situation, je ne comprends pas comment ton script pourrait fonctionner puisque dans tous les cas, $_SESSION est indépendant d'un navigateur à l'autre et donc même si tu définis les navigateurs, ceux-ci seront définis indépendamment l'un de l'autre.
Ah >_< je crois que je viens de piger, tu parles en cas de "vol" de sid ou autre faille qui permet de récupérer . Moi je parlais de manière plus générale. Cette technique serait un bon complément à mon obstruction de double connexion (qui elle est basée elle sur le fait qu'on se "log" deux fois, donc deux sessions sur un utilisateur, et non pas une session par l'utilisateur et le pirate).
Bête question mais les données renvoyées par HTTP_USER_AGENT et HTTP_ACCEPT ne peuvent-elles pas être complétées par d'autres données discriminantes de manière à améliorer le résultat ?
Et je trouve pas qu'on réinvente la roue, on cherche juste à sécuriser aux maximums les données de session, déjà rien qu'en terme de sécurité c'est un plus (dans l'absolu). Et si avec ça et un bon petit framework artisanal on arrive à limiter l'accès à la BDD, ça peut être efficace.