Posez votre question Signaler

[PHP] Cookies [Résolu]

Erdnax 2306Messages postés 1 octobre 2003Date d'inscription 29 juillet 2010Dernière intervention - Dernière réponse le 14 sept. 2005 à 17:29

Hello à tous,

Voilà, je suis en train de créer une section membre pour mon site, en php. J'aimerais, lorsque mon visiteur se logg, qu'un cookie soit généré afin de reconnaître sur les pages suivantes que l'utilisateur est connecté, et son statut.

Ma question est de savoir, car tout ce que j'ai lu sur le web m'a plus embrouillé qu'autre chose, si la sécurité n'est pas trop laxiste avec ce système. Je crée en fait deux cookies, un avec le pseudo de l'utilisateur, et un autre avec son statut, de manière a pouvoir différencier les admins des membres.

Donc est-ce qu'il y a un (gros) risque (car il y a toujours un risque ;) ) que les cookies puissent être violés ? Un cryptage est-il nécessaire ?

Merci pour vos réponses.

@+

[PHP] Cookies »

Suggestions

[PHP] Cookies
Php cookies » Articles
PHP - Récupération de données » Articles
Sécurité - Les cookies » Articles
PHP - Erreurs courantes (injection Sql, xss, upload) » Fiches pratiques
Php cookie suppression (Résolu) » Forum
Compteur de visites en php : cookie = galère (Résolu) » Forum
PHP Cookies Undefined index (Résolu) » Forum
Problème PHP cookies (Résolu) » Forum
[PHP]Cookies marchent qu'en localhost (Résolu) » Forum

Plus

Réponse

StreM 525Messages postés 18 octobre 2004Date d'inscription 14 sept. 2005 à 15:29

Je pense que ca dépend quel sécurité tu veux. Je m'explique :
Tu dois savoir qu'un cookie est stocké sur le poste client sous forme de fichier texte, sans aucun cryptage. Donc sur des systèmes basiques comme windows 98 ou même XP avec un formatage en FAT32 (pas de droits d'accès sur les répertoires), n'importe qui peut y avoir accès. Et si tu regardes le contenu du cookie, oui, c'est tout marqué en clair !
Et typiquement, c'est ULTRA SIMPLE de changer la valeur de ta variable "admin?" de non à oui !
Donc penche toi vers du cryptage/dévryptage (donc pas de MD5 !), en effet !

A moins que quelqu'un d'autre ait une solution...

http://www.securiteinfo.com/conseils/cookies.shtml

Ajouter un commentaire

Afficher les 13 commentaires

StreM - 14 sept. 2005 à 15:45

Héhééé... je pensais bien que tu pensais que j'interviendrais ;))

Sinon, pour les sessions de CCM, je pense savoir comment elles fonctionnent, car j'ai déja intervenu sur une application qui utilisait ce système, et il est vrai que ca peut servir à pleins de choses :

En fait, tu crées toi-même ton identifiant de session (un md5(rand()) et hop !), que tu stockes ET dans ta table SESSIONS ET dans ton cookie. Ainsi, tu retrouves les données dans la base de données. Problème : n'importe qui peut prendre le cookie d'un autre, et qui sait ce que ca peut donner ? A moins que tu fasses un test sur l'IP du client, mais même, point de vue de la sécurité, c'est pas génial...
Enfin de toutes facons, pour une sécurité optimum, tu ne peux que demander un identif et un mdp a chaque fois. C'est pour ca que je te demandais comment, dans quelle mesure tu comptais mettre en place ta sécu ?

Erdnax - 14 sept. 2005 à 16:09

P.S. je t'aiderai bien sur ton javascript, mais bof, j'm'y connais moi que toi. Sympa ton truc, même si c'est pas encore 100% au point, ça promet ;)

StreM - 14 sept. 2005 à 16:17

Merci !
J'ai le meme pour rogner les photos, et un autre pour les faire rotationner, négatif, etc... Bref, un photoshop online !
Mais j'aimerais bien que ca tourne pas que sous IE...
Merci quand meme !

Erdnax › Erdnax - 14 sept. 2005 à 15:52

Donc en fait, le plus simple, c'est de démarrer une session si le mot de passe et le compte d'utilisateurs sont juste, toutes les infos sont retirées à partir de la base de données (statut, droits, etc), sont stockés dans la session, et à chaque fois que le visiteur quitte le site, il doit se reconnecter.

Ca, je peux le faire, il n'y a pas de problème (c'est déjà plus ou moins en place en fait), mais j'aimerais bien pouvoir faire en sorte que le visiteur reste connecté même lorsqu'il quitte le site, durant une certaine période (en l'occurence 12h).

Donc mon problème est la sécurité avec les cookies, je ne vois pas trop comment faire en sorte que le visiteur ne puisse pas se faire voler sa session (ou même la traffiquer en fait).

StreM - 14 sept. 2005 à 16:08

Pour moi, tu devrais faire le systeme de session par BDD (tu generes toi meme l'id de session) et stocker cet id dans un cookie. Par ce système, l'utilisateur n'a AUCUN moyen de modifier son statut, puisqu'il est en BDD, pas dans le cookie. Après, il faut compter sur la sécurité du compte windows de l'utilisateur (les comptes linux n'ont pas de problemes de sécurité ;) ).
Et tu mets une date d'expiration POUR ton cookie (pas dedans ! Quand tu le crées !), et DANS ta BDD (pour ne pas que l'utilisateur puisse le modifier, et que tu puisses faire un test pour vérifier que ca ne fait pas encore 12h qu'il s'est déloggué)

Après, je te laisse réflechir pour l'utilisation optimale : n'oublie pas de mettre a jour la date de derniere connexion (dans la BDD, ca va de soi) de l'utilisateur dans chaque page.

Ca va aller ? :-P

Erdnax › Erdnax - 14 sept. 2005 à 16:32

Bon, en gros (je récapitule, parce que je suis pas sûr d'avoir tout compris.)

1. Je génère un id de session (md5(rand())) que je place dans un cookie et ma base de donnée. Ce cookie est programmé pour vivre 12h00, et son heure d'échéance est aussi indiquée dans la base de donnée.

2. Dans chaque page, on récupère le cookie, on regarde si les deux numéros de sessions jouent (bdd et cookie), et si la date d'expiration du cookie ne dépasse pas celle de la bdd.

3. A l'heure d'expiration, le cookie s'autodétruit de lui-même, et euh, dans la bdd lol ? C'est de ça que tu parles quand tu dis :

n'oublie pas de mettre a jour la date de derniere connexion (dans la BDD, ca va de soi) de l'utilisateur dans chaque page ?

StreM - 14 sept. 2005 à 16:41

NON :-P
En fait, moi j'avais vu ce systeme, et l'id que tu créeais etais passé en paramètre a chaque page. Je ne sais pas si c'est la meilleure solution...
Enfin pour utiliser ce syteme :
- index.php : tu crees l'identif de session, tu stockes dans ta BDD : l'identif de session, la date de connexion et le reste. Tu crées le cookie (a la creation, tu donnes une date d'expiration, c'est le principe du cookie),et tu mets l'identif de session dedans.
- dans les autres pages : tu actualises la date de derniere connexion dans la BDD si now() est inferieur a la date de derniere connexion + 12H sinon tu renvoie sur index.php
- index.php : tu récupères l'identif de session de ton cookie, et tu fais le test des 12H sur la date de derniere connexion. Si c'est ok, tu actualises, sinon, tu redemandes les identifiants de ton utilisateur.

Capito ? ;))
Hesite pas a me dire ce qui n'est pas clair.

Erdnax › Erdnax - 14 sept. 2005 à 16:57

Alors j'ai compris le principe, au détail près (et c'est pas le plus petit lol) du test des 12h, ce qui est souligné. Le now() est la date et l'heure de maintenant, on est d'accord ?

Je comprends pas pourquoi si l'heure actuelle est plus petite que la date de dernière connexion, alors que cette dernière est actualisée juste avant...

Et bon, si t'as du code php pour expliquer, on parlera plus le même langage lol. (Mais tu t'en doute, écris le pas s'il est pas déjà existant.)

Sinon, ce que j'ai écrit plus haut pourrait fonctionner ? Parce que ça, j'ai compris :P

StreM › Erdnax - 14 sept. 2005 à 17:06

Désolé, j'ai vu passer ca, mais j'en ai plus, de code...

Pour le inférieur, faut mettre des parenthèses :si now() est inferieur a (la date de derniere connexion + 12H)
Et oui, now() est le timestamp de ... maintenant ;)

Sinon, pour ton idée, oui ca peut tout à fait marcher, mais il y a 2 inconvénients majeurs : récupérer le cookie à chaque page, c'est lourd ! Tu n'as besoin de le récupérer qu'une seule fois si tu passes ton id de session en paramètre, ou si tu l'inscris dans une session PHP(t'emmele pas les pinceaux!). Enfin, dans ton cas, la cookie n'est pas bien gros, mais bon, pense a la bande passante, ca fait discuter 2 machines. Alors qu'un parametre en GET, non. Bref, ca peut marcher.

L'autre inconvénient, c'est que tu prends la date de connexion au tout début. Donc si ton utilisateur reste sur ton site 2H, il n'aura pas 12H de sursis, mais 10H.
M'enfin, je dis MAJEURS, mais tout est relatif !

Erdnax › Erdnax - 14 sept. 2005 à 17:17

AAAAAAAAAHHHHHHHHHH

Ben avec les paranthèse, ça va bien mieux lol !

Sinon, tu t'embrouilles sur l'explication de la lourdeur si je récupère le cookie sur chaque page, mais j'ai tout compris, sisi !

Et sinon, pour les 10 ou 12 heures, bof, ça m'est égal, c'est totalement aléatoire, c'est juste histoire que le cookie ne reste pas trop longtemps, mais le temps exact n'est pas très important, donc ce n'est pas un inconvénient.

Donc je crois que je vais prendre "ma" méthode, avec une seule récupération du cookie.

Le seul truc, c'est pour enlever les id de sessions terminées dans la base de donnée. Si t'as une dernière idée pour ça ;)

StreM › Erdnax - 14 sept. 2005 à 17:27

Pardon, il est le soir, j'ai travaillé toute la journée, je commence a fatiguer, j'arrive plus a m'expliquer... :-P
Pour nettoyer un peu la BDD des sessions je pense que je ferais une fonction qui parcourt la base a la recherche des "last_time_connect" qui datent de plus de 12H.

Je déduis de ton post que tu utiliseras bien des tables liées ?
genre une table qui ne contient QUE l'id de session et l'id du user, et une autre table qui contient les users ?
Si c'est ca, c'est bien, j'avais oublié de le préciser. Tu verras que ca peut être drôlement utile !

Bon courage en tout cas ! Je te laisserais te dépatouiller, tu apprendras beaucoup avec un script comme ca ! Mais réflechis bien à tout, c'est pas évident de se lancer la dedans, mine de rien !

Erdnax › Erdnax - 14 sept. 2005 à 17:29

Je sais, merci pour tout, mais je n'ai averti personne de ce projet. (Bien que les visiteurs ne soient pas encore foule). J'ai donc tout le temps qu'il me faut pour développer, tester, etc.

Donc encore merci, et bonne soirée, repose toi bien ;)

:P@+