[PHP] Securité: sendcookie fiable?

Securité: sendcookie fiable? [PHP] - PHP - Programmation

Marsh Posté le 16-01-2005 à 18:48:34    

Simplement je voulais savoir ce que vous pensiez de l'identification par cookie sur un site (pour aller dans un espace membre). Est ce fiable au niveau securité? N'y a t il pas de risque d'etre pirater?  
 
Comment peut on s'y prendre le cas échéant pour reconstruire un cookie de mon site?
 
Merci à tous

Reply

Marsh Posté le 16-01-2005 à 18:48:34   

Reply

Marsh Posté le 16-01-2005 à 19:01:38    

Je te conseille deja d'utiliser une session a la place de cookies


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 16-01-2005 à 19:16:03    

esox_ch a écrit :

Je te conseille deja d'utiliser une session a la place de cookies


 
Heu je suis pas d'accord avec toi  :non: :
Si tu n'utilises pas les cookie pour les sessions, l'id session passe en clair dans l'url alors qu'avec les cookie c'est pas le cas. Donc avec les cookies c'est mieux.  

Reply

Marsh Posté le 16-01-2005 à 19:32:04    

Et on ne peux pas "imiter" ce que contient un cookie? Par exemple en écrivant un autre cooke?

Reply

Marsh Posté le 16-01-2005 à 19:37:05    

non, ton serveur n'accepte que les cookies qu'il a créé.

Reply

Marsh Posté le 16-01-2005 à 19:38:31    

merci sonikbuzz

Reply

Marsh Posté le 16-01-2005 à 20:15:46    

Les sessions utilisent a leur facon les cookies bien entendu, mais je les trouve beaucoup plus sures parceque par exemple je stoque dans les variables de sessions des info que je ne veux pas que l'utilisateur puisse connaitre, ce qui est difficilement realisable avec les cookies vu qu'ils sont stockés cotés client.
 


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 16-01-2005 à 23:59:01    

esox_ch a écrit :

Les sessions utilisent a leur facon les cookies bien entendu, mais je les trouve beaucoup plus sures parceque par exemple je stoque dans les variables de sessions des info que je ne veux pas que l'utilisateur puisse connaitre, ce qui est difficilement realisable avec les cookies vu qu'ils sont stockés cotés client.


 
Tu peu les crypter

Reply

Marsh Posté le 17-01-2005 à 02:10:03    

panic02 a écrit :

Et on ne peux pas "imiter" ce que contient un cookie? Par exemple en écrivant un autre cooke?

sonikbuzz a écrit :

non, ton serveur n'accepte que les cookies qu'il a créé.


:non: On peut mettre ce que l'on veut dans un cookie et le donner au serveur. C'est juste qu'un autre serveur ne pourra pas lire le contenu de tes cookies.

Reply

Marsh Posté le 17-01-2005 à 07:24:16    

sonikbuzz a écrit :

Tu peu les crypter


 
Oui mais je trouve quand meme beaucoup plus utiles les sessions. Elles ont une taille  illimitée, nombre de variables illimitées, les risques d'interception de la part d'un tier ne sont pas plus hauts qu'avec les autres scripts (ton truc du id session passé dans l'url je comprend pas trop a quoi tu fais reference).


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 17-01-2005 à 07:24:16   

Reply

Marsh Posté le 17-01-2005 à 08:16:56    

esox_ch a écrit :

Oui mais je trouve quand meme beaucoup plus utiles les sessions. Elles ont une taille  illimitée, nombre de variables illimitées, les risques d'interception de la part d'un tier ne sont pas plus hauts qu'avec les autres scripts (ton truc du id session passé dans l'url je comprend pas trop a quoi tu fais reference).


 
Attention quand meme, les sessions peuvent etre vulnerables mais sur le serveur.
Si tu es heberge sur un serveur mutualise, tes "voisins" peuvent "pirater" tes sessions, bon me semble que c'est pas possible s'il y a le safe mode, mais les sessions ne sont pas "secures".
 
Sinon, il me semble que sonikbuzz fait reference a l'id qui identifie les sessions. En effet quand tu cree une session cette derniere a une id. Cette id sert a la differencier des autres sessions. Mais voila, pour que le serveur sache a quel client appartient telle ou telle session, le client doit lui envoyer le session id.
La 2 methodes :
1) Surement la plus utilisee, c'est de stocker l'id de session dans un cookie chez le client. Cookie avec une duree de vie limitée qui n'est valable que le temps de la session du navigateur. Une fois ferme, le navigateur detruit le cookie.
2) Si le client n'accepte pas les cookies, alors on peut passer l'id de la session par l'url. Cette methode va "creer" des urls du type : "www.monsite.com/mapage.php?PHPSESSID=14524632155".
Ces 2 methodes sont "gerees par php", c'est pourquoi on a tendance a les oublier. Il existe d'ailleurs un parametre php pour lui dire s'il doit ajouter lui meme de facon autmatique le "PHPSESSID=..." a la fin des urls.
 
Enfin bref, dans les deux cas, l'unique chose a laquelle le client peut acceder est l'id de la session. Ici l'unique moyen pour lui de "pirater" une autre session c'est de connaitre son id... Les ids sont faits de telle maniere qu'ils peuvent difficilement etre "devines", donc a moins d'avoir un access quelconque au pc de la "victime" c'est quasiment "impossible".
La plus part du temps on prefere entrer par un autre endroit. Prenons un exemple. Admetons que vous stockez, dans un cookie, le "login" et le "md5" du password d'un user. Comme ca des qu'il revient sur le site, ce dernier detecte la presence du cokiie, puis apres verification du login et du mot de passe autorise l'utilisateur et lui cree une session.
Ici le hacker aura plutot tendance a pirater le site via une attaque du type de "sql injection" afin de recuperer un couple "login / md5(password)" que pirater la session php. Cette derniere etant plus dure a trouver, alors que le fait de pirater la bdd via une "sql injection attack" lui sera surement plus facile.
 
Avec cet exemple relativement simple on peut se rendre compte que le probleme ne vient pas forcement des cookies et/ou sessions, mais plutot de la facon generale dont le site est concu. Le simple fait que le site "reconnaisse" un utilisateur et le relogue sans lui redemander un password peut etre le point faible de votre site. Et dire qu'a l'origine vous ne vouliez que "faciliter la vie des utilisateurs" ont leur evitant de se re authentifier a chaque fois ...
 
Avec cet exemple on peut egalement voir que le fait que les infos soient "cryptees" ne changent pas bcp. Ici le mot de passe est "crypte" puisqu'il n'est pas stocke en clair dans le cookie. Neanmoins sa formee cryptee y est. Le probleme reside plus sur le fait que "la meme information" se trouve a la fois dans le cookie est dans la bdd. Une parade pourrait etre de ne pas utiliser le meme algo dans le cookie est dans la bdd. Mais un autre probleme survient... Generalement le mot de passe n'est jamais stocke en clair dans la bdd pour eviter des problemes si jamais la bdd vient a etre compromise. Mais s'il n'est pas sotcke en clair alors il y a pas vraiment de "moyen" pour pouvoir creer deux "cryptages" differents.
Si le password etait en clair il suffirait d'utiliser md5 dans un cas, puis par exemple sha-1 dans un autre. On pourrait toujours les "comparer" puisqu'on aurait une base commune. Mais cela n'est pas le cas, donc c'est pas vraiment faisable...  
On pourrait "re crypter" le cryptage du mot de passe, mais cela ne fait pas bcp de difference, une fois que le hacker sait quel algo vous avez utilise pour "re crypter" le mot de passe ca ne sert plus a rien...
 
Ce qui pourrait eventuellement augmenter un peu le sentiment de securite serait de stocker en crypte le nom de l'utilisateur. Mais la un autre probleme survient.
Soit vous utilisez un "vrai" cryptage (donc reversible) et a ce moment une fois l'algo "devine" c'est comme s'il n'existait pas.
Soit vous utilisez un "faux" algo de cryptage (donc non reversible) et a se moment votre procedure de login ralentit proportionnelement aux nombre d'utilisateurs enregistres sur le site. Ben oui faut faire un boucle et a chaque fois comparer le cryptage de l'utilisateur que l'on teste avec la valeur du cookie. Il existe d'ailleur un autre probleme, il se peut que deux utilisateurs aient la meme valeur de "cryptage", bon il reste encore le "password" mais (et si ce dernier etait le meme ?)...
 
 
Enfin voila, apres cette longue tirade j'espere vous avoir montre que le probleme n'est pas vraiment la ou on le pense. Et je pense que la meilleure solution reste quand meme la session pour stocker "le boolean indiquant si l'user est logue" (stocker se bool ds un cookie n'est vraiment pas la bonne solution, car le cookie est facilement modifiable).

Reply

Marsh Posté le 17-01-2005 à 08:47:54    

belgique a écrit :

:non: On peut mettre ce que l'on veut dans un cookie et le donner au serveur. C'est juste qu'un autre serveur ne pourra pas lire le contenu de tes cookies.


 
quand je me suis penché sur le fonctionnement des cookies, pour essayer de comprendre, j'ai fait pas mal de test en local (avec easyPHP).
Truc basique, un cokkie avec le pseudo, quand tu arrive sur le site, si le cookie existe il te logue direct, enfin rien de bien innovant.
J'ai essayé à plusieurs reprise de modifier le contenu du cookie (autre pseudo par exemple)  avec un éditeur de texte, ben quand je retournai sur le site, celui-ci se comportait comme si le cookie n'existait pas
--> je suis donc plutot d'accord avec sonikuzz quand il dit:

Citation :

 non, ton serveur n'accepte que les cookies qu'il a créé.



---------------
- Xav - ...There are no crimes when there are no laws... -- Xav's World
Reply

Marsh Posté le 17-01-2005 à 12:04:27    

Si tu ne sais pas modifié un cookie, j'y peux rien :o.
 
Peux tu m'expliquer comment le serveur distingue un cookie non modifié d'un cookie modifié? ;)

Reply

Marsh Posté le 17-01-2005 à 12:36:23    

Cerel > Justement, si tu utilises une session avec le phpID dans un cookie c'est deja pas mal securisant, c'est clair qu'on peut encore cracker le serveur pour pouvoir chopper la session et la modifier .. mais ça c0'est une autre histoire


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 17-01-2005 à 13:40:35    

belgique a écrit :

Peux tu m'expliquer comment le serveur distingue un cookie non modifié d'un cookie modifié? ;)


paske j'utilise les sessions, que j'oblige l'ID de session à passer par cookie (via un ini_set())


---------------
- Xav - ...There are no crimes when there are no laws... -- Xav's World
Reply

Marsh Posté le 17-01-2005 à 13:44:29    

Je parle du fait que selon toi les cookies ne pourraient être modifiés ;)

Reply

Marsh Posté le 17-01-2005 à 16:24:27    

belgique a écrit :

Je parle du fait que selon toi les cookies ne pourraient être modifiés ;)


 
selon le site suivant:
http://www.adia.fr/Contenu/pages/p_mentions.asp
 
je cite:

Citation :

INFORMATION SUR LES COOKIES
 
Technique : un "cookie" est un enregistrement d'informations par un serveur dans un fichier texte situé sur l'ordinateur client (le vôtre), informations que ce même serveur (et lui seul) peut aller relire et modifier ultérieurement.
La technique des cookies repose sur le protocole HTTP, c'est-à-dire le protocole du web. Il ne faut donc pas voir de cookies partout : seul un serveur web peut en envoyer. Plus précisément, un cookie se compose d'un ensemble de variables (ou de champs) que le client et le serveur s'échangent lors de transactions HTTP, lesquelles variables sont tout simplement stockées sur la machine cliente dans un simple fichier texte.
 
Un cookie est obligatoirement rattaché à un nom de domaine et un ensemble d'URL de telle sorte que seule une requête provenant du même serveur peut y accéder.
Par exemple, grâce à un programme CGI, le serveur a la possibilité de mettre à jour ou d'effacer un cookie. Mais pour cela, il doit spécifier tous les attributs du cookie, par conséquent seul le serveur qui a créé un cookie peut le modifier ou le supprimer. Un même "client" peut stocker un maximum de 300 cookies, dont 20 maximum pour un même serveur, chaque cookie pouvant atteindre jusqu'à 4000 octets (env. 4 Ko).


 
tu dis:

Citation :

Si tu ne sais pas modifié un cookie, j'y peux rien :O


ben moi non plus :O


---------------
- Xav - ...There are no crimes when there are no laws... -- Xav's World
Reply

Marsh Posté le 17-01-2005 à 16:40:16    

Xav_ je crois que ce que l'article que tu presentes signifie qu'un site ne peut modifier/supprimer seulement les cookies qu'il a créé lui meme, mais le client peut sans doutes modifier les cookies qui sont dans son ordio


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 17-01-2005 à 16:41:46    

Il est possible de modifier les cookies. Par contre il est possible que certains browser integrent un systeme de "checksums" afin de verifier que le cookie n'as pas ete corrompu. Mais neanmoins on peut modifier les cookies et meme les creer. Me semble avoir vu trainer un utilitaire du genre pour IE. Il permetait de forger des cookies pour n'importe quel site.

Reply

Marsh Posté le 17-01-2005 à 16:55:51    

si ce que j'ai pu lire ainsi que les tests que j'ai fait sont faut, merci par avance de me le prouver...  
le cas échéant je reconnaitrais de bon coeur m'etre trompé...  
 
bien sur qu'avec un éditeur de texte tu modifie un cookie sans pb, sauf que chaque fois que je l'ai fait pour tester, le site d'origine ne tenait plus compte du cookie modifié...
Le serveur arrive à reconnaitre un cookie "modifié" meme si je sais pas exactement comment...
 


---------------
- Xav - ...There are no crimes when there are no laws... -- Xav's World
Reply

Marsh Posté le 17-01-2005 à 20:09:20    

Dans ton article il faut comprendre comme dit plus haut que presencepc peut pas lire des cookies de hfr(les exemples :D).
Enfin moi je suis sûr de moi, je l'ai déjà fait et ça marche, j'ai rien à te prouver. Maintenant si tu ne veux pas me croire libre à toi :). (Tu peux me filer le contenu de ton cookie sur ton forum, tu verras je saurai me loguer. Maintenant c'est une mauvaise idée :D)

Reply

Marsh Posté le 17-01-2005 à 20:26:09    

Citation :

c'est une mauvaise idée

c'est kler


---------------
- Xav - ...There are no crimes when there are no laws... -- Xav's World
Reply

Marsh Posté le 17-01-2005 à 22:04:37    

Tiens vu que ca parle de session et de cookie ...
 
Question bête (mais alors très) :
 
Si on utilise les sessions, les cookies expire à la fermeture du navigateur. Mais si on veut que ce meme cookie aie une autre date d'expiration, c'est possible ?


---------------
http://www.alsacreations.com , http://www.openweb.eu.org. Mon CV : http://cv.roane-irkana.net/. Exemple à ne surtout pas suivre : www.worldinternet.be
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed