Discussion :

[spilliaert]

oui, regardez par exemple à cette page, vous verrez; un cookie de session a les même caractéristiques qu'un cookie "normal":

http://be.php.net/manual/fr/function...kie-params.php

[psychoBob]

oui, regardez par exemple à cette page, vous verrez; un cookie de session a les même caractéristiques qu'un cookie "normal":

Bon alors là Spilliaert je m'y retrouve plus, parce que deux posts au dessus tu dis :

COOKIE[session_name()] est le cookie de session, pas un cookie "normal" ...la preuve1 er exemple, qui détruit le cookie de session

Quelle différence fait tu entre ces deux affirmations ô combien téméraires ?

[berceker united]

Une cookie est un cookie il y a pas de cookie spécial par rapport au navigateur. La différence ce fait sur celui qui l'a créé. Soit c'est un script soit c'est le serveur.
SESSION : Du coté serveur il y a un fichier par utilisateur (sauf JSP(TOMCAT) qui peut créer une session partagé par plusieurs utilisateur) qui est créé avec les information.
COOKIE : Du coté client il y a comme valeur ssid qui correspond au fichier present dans le serveur.
Lorsque le serveur voit un client avec son cookie ayant comme nom de valeur PHPSSID ou un autre nom définit dans le php.ini à la ligne [session.name] il récupére la valeur dans PHPSSID et compare avec le fichier session present dans le serveur.
Il suffit de faire un test. De regarder dans le repertoire ou est stocké les session. Elle peut être définit dans le php.ini à [session.save_path] . "Je crois" que le nom du fichier correspond au nom du PHPSSID et le contenu est serialisé.

Il est très simple d'imiter le comportement des session via une base de données. Ce fut le cas avec une version de php3 qui avait était pas sécurisé. la plupart des applications passait par une base de données.

Le gros problème de sécurité est du faite que le serveur est incapable de ciblé un utilisateur sans un cookie et que si ce même cookie se trouve sur une autre machine il ne fera pas la différence pour lui ça sera le même utilisateur.
Il y a des petites technique qui consiste à gérer le temps de validité du cookie donc de la session. De brouiller les pistes en changeant le nom de la valeur du session.name. d'en placer plusieurs pour le noyer dans un flot d'information. De le changer en temps reelle. De limiter les porté. etc...
Il y a pas vraiment de possibilité d'antivol de cookie. Le seul moyen correcte reste le HTTPS.

[psychoBob]

Une cookie est un cookie il y a pas de cookie spécial par rapport au navigateur. La différence ce fait sur celui qui l'a créé. Soit c'est un script soit c'est le serveur.
Sainte réponse, j'ai compris (bon ok, je crois avoir compris quelque chose. C'est plus clair. Bon d'accord, disons que c'est moins sombre).

Une question :
Sur mon site je fais cela :

Code :

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

1
2
3
4
5
6
<?php
if( isset( $_COOKIE[ session_name() ] ) )
{
    session_start();
}
?>

Le but est d'interdire que les sessions passent dans l'url et que cela ne fonctionne qu'avec des cookies (je n'ai pas su me débrouiller avec le sesision_use_only_cookie ou un truc comme ça).
Mais curieusement, lorsque j'interdis au navigateur d'accepter les cookies, les sessions fonctionnent toujours, sans pour autant passer par l'url.
Serait-ce là une preuve que les cookies de sessions ne sont pas géré comme les cookies "normaux" par les navigateurs ?

Une autre question sur la sécurité :
On a pas mal parlé sur le forum d'un système qui déconnecte l'utilisateur et l'éventuel pirate en comparant un id de session et un md5 alétoire passé en cookie et régénéré à chaque page. Si le pirate vol la session, de toute façon il n'a pas le même numéro dans le cookie et donc les deux sont déconnectés.
Donc :
un cookie de session se vole-t'il comme un cookie normal ? Auquel cas le procédé ci-dessus ne fonctionne pas avec les sessions qui circulent via les cookies puisque le pirate vol les deux indifféremment.

[berceker united]

Attention !
.Quand tu as interdit les sessions a ton navigateur as tu vidé les précédente ?
.Tu as bien regardé dans les repertoires qui stock tes session qu'il est vide ?
.Du coté du serveur à tu vus un fichier se créer au moment ou tu appelles la .page qui initialise la session ?
.Cette session est elle exploitable ? ou tu es resté sur la même page ?

[psychoBob]

Bon alors je viens de refaire les tests :
1)
- Je vide les cookies.
- Je m'identifie.
- je vérifie dans firefox, je vois un cookie :
site.com PHPSESSID (contient l'id :6f939e0d08f4e98579fc77c79b38601f)
==> ça fonctionne.
2)
- Je vide les cookies
- J'interdis les cookies
- Je m'identifie.
- La session est visible dans l'url pour la première page.
- Je change de page : je suis déconnecté.
==> apparemment ça fonctionne aussi.

Quelques questions :
a) Normalement , je devrais préciser aux utilisateurs d'accepter les cookies pour pouvoir utiliser le site, non ?
b) Si quelqu'un veut voler une session il va lui falloir je pense un script xss désactivé par htmlspeciachars pour pouvoir ouvrir les cookies présent sur le navigateur de la victime, non ? (Au fait si ça passait par l'url, même caché, en quoi cela serait-il plus facile à voler).
3) J'initialise deux cookies à l'identification : l'un comme je fais déjà, le cookie de session + un deuxième cookie "normal" avec un md5(). J'envoie dans la session le même numéro que dans le cookie normal.
A la page suivante je compare les deux, si ils sont identiques c'est bon, sinon je déconnecte. Si ils sont identiques je réinitialise ces deux md5().
Ainsi de suite à chaque page.
Donc là le pirate vole l'id de session, mais il n'a pas l'autre ou alors un avec un numéro différent ou alors il va falloir qu'il le vole.
DONC : peut-on voler un cookie "normal" comme on vole un cookie de session ? Si non, cette solution semble bien pour désactiver utilisateur et pirate en cas de vol.

[spilliaert]

Bon alors là Spilliaert je m'y retrouve plus, parce que deux posts au dessus tu dis :
...


Quelle différence fait tu entre ces deux affirmations ô combien téméraires
...
?

la différence, c'est que je parle de "caractéristiques communes" (expiration, path,domaine,SSL)et d' "égalité"...comme dit plusieurs fois dans ce post; un cookie de session et un cookie "normal" ne sont pas égaux

cookie "normal"==>
*contient <nom_de_variable>+\n+<valeur>+numéros+*+<nom_de_variable>+\n ....
*stocké sur le HDD du client

cookie session==>
*contient UNIQUEMENT le session_id
*stocké sur la mémoire vive du navigateur client

LES 2 TYPES DE COOKIES SONT STOCKES CHEZ LE CLIENT !
bon, maintenant, si tu piges pas



maintenant:
il y a 2 manières au navigateur client de transmettre le session_id au serveur, qui va lui permettre d'aller chercher le bon fichier de session:

*soit avec ce fameux cookie de session
*soit par URL avec www.monsite.com/index.php?PHPSESSID=zer456ze4654fsdfsdfsdfnhsdgil

Bon alors je viens de refaire les tests :
1)
- Je vide les cookies.
- Je m'identifie.
- je vérifie dans firefox, je vois un cookie :
site.com PHPSESSID (contient l'id :6f939e0d08f4e98579fc77c79b38601f)//cookie de session
==> ça fonctionne.//ok
2)
- Je vide les cookies
- J'interdis les cookies //pas de cookie donc PHPSESSID passé en $_GET
- Je m'identifie.
- La session est visible dans l'url pour la première page. //c'est bien ce que je dis
- Je change de page : je suis déconnecté.
==> apparemment ça fonctionne aussi. // all right

donc, cookies autorisées ou pas, les sessions fonctionnent

pour la technique que tu dis avec le session+md5 dans cookie, paraît assez bonne; elle permet d'être plus sûr que l'initialiseur de la session est bien celui qui l'utilise...

comme le dit berceker united, il n'y a pas de "recette magique" qui protège contre le vol de session (du moins, c'est ce que disent plusieurs personnes et livres compétents).

ce que je dis sur les différences cookie normal/session, sont le fruit des explications de Sylvain71 + le résultat de recherches personnelles depuis l'ouverture de ce post (recherches que tu aurais pu aussi faire...)

Pour savoir comment un pirate peut voler un cookie (chez le client, hein, );

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

[psychoBob]

bon, maintenant, si tu piges pas

Je préfère pas croire trop vite que j'ai pigé

donc, cookies autorisées ou pas, les sessions fonctionnent

Non pas du tout, la session est supprimée si j'interdit les cookies, elle n'existe que pour la première page, car je ne sais pas pourquoi mais php semble hésiter entre la passer par les cookie ou l'url.
Comme après je force le passage par cookie la session est supprimée si les cookies sont interdits : c'est pour ça que je dis que ça fonctionne, parce que je ne veux autoriser QUE les sessions par cookie.

pour la technique que tu dis avec le session+md5 dans cookie, paraît assez bonne; elle permet d'être plus sûr que l'initialiseur de la session est bien celui qui l'utilise...

Oui mais pour en être sur je voudrais être certain qu'un cookie "normal" ne se vole pas comme un cookie de session, sinon j'aurais beau en faire deux pour les comparer, si le pirate en vol un, il pourra tout aussi bien voler les deux.

Pour savoir comment un pirate peut voler un cookie (chez le client, hein, )

Je vais lire le lien, merci, si ça se trouve ça répondra un peu à ma question juste au dessus, m'enfin ne vous privez pas de dire ce que vous en pensez.

[spilliaert]

Comme après je force le passage par cookie

Comment fais-tu ? avec session.use_cookies ?

[psychoBob]

Non je fais ça, comme dit plus haut :

Code :

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

1
2
3
4
5
6
7
 
<?php
if( isset( $_COOKIE[ session_name() ] ) )
{
    session_start();
}
?>

J'ai pas réussi à faire fonctionner session.use_cookies.

[spilliaert]

ce code ne force pas du tout le passage par cookie, comme je l'explique plus haut

[psychoBob]

Alors comment expliques-tu que si j'interdis les cookies dans le navigateur, la session soit déconnectée après la première page ?

[berceker united]

Non je fais ça, comme dit plus haut :

Code :

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

1
2
3
4
5
6
7
 
<?php
if( isset( $_COOKIE[ session_name() ] ) )
{
    session_start();
}
?>

J'ai pas réussi à faire fonctionner session.use_cookies.

tente de passer par la fonction init_set. Cette fonction permet de rédéfinir certaine configuration de php.ini

[psychoBob]

Je suis en mutualisé, je précise à tout hasard...


Une question qui me trotte dans la tête :
Pour afficher ou non certains scripts, je fais

Code :

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

1
2
if(isset($_SESSION['numeroSession']))
{le script;}

est-ce que c'est plus ou moins sûr que :

Code :

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

1
2
if(isset($_COOKIE[ session_name()]))
{le script;}

Sachant que dans le premier cas, le pirate ne connait pas à priori le nom de la variable de session tandis qu'il n'a pas besoin de connaitre un quelconque nom dans le second. Donc peut-être peut-il, en cas de test sur l'existence du cookie de session, créer artificiellement un cookie ?
Je vais me faire frapper mais bon faut que je sois sur là.