Sécurité, onglets et cookies/sessions - Page 1

1

Le 03/03/2006 à 09:57

J'ai un problème... J'utilise une session pour authentifier des usager. Ca marche bien, sauf que les navigateurs à onglets ne droppent pas les cookies ni les variables de session si on ferme l'onglet (et qu'on en rouvre un par la suite).
Ca me pose quelques soucis, et je me demandais comment faire (comment fait par exemple yAro pour que quand on décoche "se souvenir de moi" on soit authentifié jusqu'à la fermeture de l'onglet... j'imagine qu'il n'utilise pas des formulaires avec des types cachés, c'est pas forcément secure, si ?)

En outre j'ai l'impression que certaines variables de cessions ne s'affectent pas comme il faudrait (valeurs vides), sans que je comprenne pourquoi.

Je ne sais pas si ma question est assez claire...

2

Le 03/03/2006 à 10:47

c'est en quoi ? php ? asp ? autre chose ?

3

Le 03/03/2006 à 11:03

Du PHP en l'occurence.

4

Le 03/03/2006 à 20:24

Quand on décoche la case sur yN il n'y a que les sessions ($_SESSION) qui sont utilisées, sinon y'a un cookie ($_COOKIE), à part celà je ne fais rien de spécial pour que ca marche juste sur un onglet

Webmaster et développeur du site. Pour tout probleme ou question envoyez un mini message ou mail.

Suivez l'actualité de tous vos site préférés sur yAronews : http://ns.yaronet.com =)

5

Le 03/03/2006 à 21:01

Muh ? C'est bizarre... Ca vient peut-être de paramètres de PHP, mais on a remarqué ce comportement avec tous nos serveurs en production

6

Le 04/03/2006 à 07:33

La solution serait alors de créér une page 'déconnexion' (C'est un peu idiot avec les sessions mais bon :/) avec un session_destroy() à l'intérieur.

Sinon, dans le php.ini faudrait peut être modifier une valeur :
session.gc_maxlifetime entier

Spécifie la durée de vie des données sur le serveur, en nombre de secondes. Après cette durée, les données seront considérées comme obsolètes, et supprimées.

7

Le 04/03/2006 à 10:25

Hmm j'ai fait autrement. L'utilisateur ne voit que le fichier index.php. Tout le reste est appelé en fonction de conditions. Or un appel de index.php fait un session_destroy et une vidange des cookies. Comme l'utilisateur n'a pas de moyen de connaître le nom des autres fichiers (ou alors bon courage pour les trouver), on va dire que le degré de sécurité est satisfaisant compte tenu du fait que l'application n'est pas critique.

Je ne peux pas travailler avec "session.gc_maxlifetime entier" tout simplement parce que la dernière opération de l'appli est un upload pouvant aller jusqu'à 4 Mo et les étudiants doivent pouvoir uploader leur document même depuis une ligne RTC (bon, il leur faudra beaucoup de courage, mais c'est spécifié dans le cahier des charges).

8

Le 16/03/2006 à 16:31

Nil a écrit : les navigateurs à onglets ne droppent pas les cookies ni les variables de session si on ferme l'onglet (et qu'on en rouvre un par la suite).

Comment ça, dropper les cookies ? Les enregistrer sur le dur ?
Je n'ai malheureusement encore jamais bossé avec des cookies, donc je ne peux pas t'aider.

Par contre, pour les variables de session, c'est normal qu'elles ne s'enregistrent pas, leur rôle est uniquement de persister d'une page PHP à une autre au cours d'une même session

!
Et 1 session == 1 thread du navigateur, or N onglets == N threads : ouvrir 2 onglets sous Firefox est strictement équivalents (fonctionnellement parlant : le gestionnaire de tâches indique un seul processus firefox.exe) à ouvrir 2 fenêtres Internet Explorer, il n'y a aucune communication entre les onglets.
Et enregistrer des variables de session pour pouvoir fermer un onglet et les récupérer dans un autre, ça s'appelle faire un cookie

!

Mais bon, vu que tu sais déjà tout ça, j'ai sans doute mal compris ta question ...

Ainsi que : En outre j'ai l'impression que certaines variables de cessions ne s'affectent pas comme il faudrait (valeurs vides), sans que je comprenne pourquoi.

A l'initialisation ou lors des transactions ?
Pour résoudre ça, j'ai créé 2 fichiers '_Init_Session.inc.php' et '_Reception_POST.inc.php', inclus au tout début du <body> de 'index.php' qui, comme dans ton cas, est le seul visible :
[li]_Init_Session.inc.php initialise (réinitialise à chaque fois, plutôt) les variables globales utilisées dans la plupart des pages appelées par 'index.php', et initialise les variables de session (une seule fois, avec if ( !isset( $_SESSION[ 'Ses_Var_1' ] ) ) { $_SESSION = array( 'Ses_Var_1' => "Tapoué !", 'Ses_Var_2' => 42 ) ; } ... tu vois le principe)
[li]_Reception_POST.inc.php récupère toutes les données de $_POST lors d'un changement de page (if ( isset( $_POST ) { foreach ( $_POST as $Key => $Value ) { ... } }) et les copie dans la session avec le bon typage (un peu salement, mais bon, j'ai des circonstances atténuantes ^^)
Attention !!! J'ai fait ça à mes tous débuts en PHP, il y a 2 ans et demi, donc je doute que ce soit la meilleure solution (sans compter le typage lors de la copie $_POST -> $_SESSION, il faudrait vraiment que je cherche une méthode plus propre et flexible ...).

Désolé de ne pouvoir t'aider pour les cookies, il faudrait vraiment que je m'y mette un jour, ça pourrait servir.

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

9

Le 16/03/2006 à 18:45

Et 1 session == 1 thread du navigateur, or N onglets == N threads : ouvrir 2 onglets sous Firefox est strictement équivalents (fonctionnellement parlant : le gestionnaire de tâches indique un seul processus firefox.exe) à ouvrir 2 fenêtres Internet Explorer, il n'y a aucune communication entre les onglets.
Et enregistrer des variables de session pour pouvoir fermer un onglet et les récupérer dans un autre, ça s'appelle faire un cookie !

C'est ce que je pensais... jusqu'à maintenant. Je vais sur mon site sur un onglet, je me connecte, j'ai un PHPSESSID avec des infos de session côté serveur. Je ferme l'onglet, j'en ouvre un autre, retourne sur mon site, et j'ai le même PHPSESSID, avec les mêmes infos de session côté serveur

10

Le 16/03/2006 à 20:27

Les variables de session sont conservées ?
Tu ne disais pas le contraire, justement, en ./1 ???

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

11

Le 16/03/2006 à 21:33

J'ai un problème... J'utilise une session pour authentifier des usager. Ca marche bien, sauf que les navigateurs à onglets ne
droppent pas les cookies ni les variables de session si on ferme l'onglet (et qu'on en rouvre un par la suite).

Nonon

Bon, on a trouvé une technique qui fait que ce n'est pas critique (il n'existe qu'un seul fichier accessible par l'utilisateur, index.php, et il appelle tous les autres qui sont accessibles par le webuser, mais pas par le démon apache).

12

Le 16/03/2006 à 21:49Edité par Ethaniel le 17/03/2006 à 09:40

j'ai écrit :
Comment ça, dropper les cookies ? Les enregistrer sur le dur ?

Erf, j'avais compris 'dropper' dans le sens inverse

...

[edit]Oubli de fermeture de balise

[/edit]

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

13

Le 16/03/2006 à 23:06

Hmmm non je voulais dire ne pas dropper dans le sens ne pas vider/éliminer/laisser tomber

14

Le 17/03/2006 à 09:46

Pour les cookies, c'est normal qu'ils ne soient pas effacés, mais pour les variables de session ...
Je n'avais jamais fait le test, je viens de le réaliser à l'instant, et en effet, les variables de session sont conservées d'un onglet sur l'autre, et je ne vois pas comment corriger ça

...

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

15

Le 17/03/2006 à 11:25

Ethaniel :

Les variables de session sont conservées ?
Tu ne disais pas le contraire, justement, en ./1 ???

Les variables de sesssion sont stockées côté serveur. Et le serveur il se contrefiche de savoir (en l'occurence de ne pas savoir) combien tu as de fenêtres ouvertes.

« Dream is destiny »

16

Le 17/03/2006 à 12:17

Sauf que dans ma tête, une page ouverte = un socket ouvert = une session php, et une page ouverte = un onglet ouvert, donc ça ne devrait pas fonctionner de cette façon...

17

Le 17/03/2006 à 12:59

Nope. HTTP est un protocole sans états. Chaque requête est traitée de manière totalement indépendante aux suivantes et aux précédentes.
Le navigateur sait maintenir une connexion pour enchainer des requêtes, mais au bout de quelques secondes (une dizaine par défaut je crois) il la ferme.

L'ajout d'une gestion d'états, quand nécessaire, est réalisée au dessus, par exemple par des cookies. C'est d'ailleurs ce qui se passe quand tu utilises les variables de session :

- PHP crée un répertoire temporaire par session, identifié par un identifiant
- il envoie cet identifiant dans un cookie, par défaut PHPSESSID

« Dream is destiny »

18

Le 17/03/2006 à 13:29

En fait, avec Firefox (et sans doute tous les Mozilla), ça va plus loin que ça : tant qu'il y a toujours au moins une fenêtre FF ouverte, les variables de session sont gardées.
Exemple : j'ouvre une première fenêtre FF, je vais sur ma page et modifie quelques variables de session, j'ouvre une seconde fenêtre FF (pas un onglet, une fenêtre) vers la page d'ouverture (yN

), je ferme la 1^re, j'ouvre une 3^e fenêtre, je ferme la seconde qui n'a donc jamais mis les pieds sur ma page, et, dans la troisième, j'ouvre ma page ... et y retrouve mes variables de session modifiées ...
Et ce, même après 10 minutes d'inactivité sur ma page (enfin ça, ça doit être ma configuration Apache qui veut ça).
Inversement, avec IE, si j'ouvre une fenêtre, regarde ma page et modifie des variables de session, une seconde fenêtre IE en parallèle n'est pas au courant et n'a pas ces variables modifiées.

[edit]En fait, je viens de voir dans le 'Gestionnaire des tâches' que N fenêtres IE == N threads IEXPLORE.EXE, alors que N fenêtres FF == 1 thread firefox.exe ...
C'est donc le choix respectif de gestion des threads qui explique la différence.[/edit]

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

19

Le 17/03/2006 à 14:23

...

Je crois que y'a de sacrés notions de réseau qui manquent

(surtout sur le protocole http)

tant qu'il y a toujours au moins une fenêtre FF ouverte, les variables de session sont gardées

Le variables de sessions ne sont pas enregistrées chez toi, mais sur le serveur web.

enfin ça, ça doit être ma configuration Apache qui veut ça

Apache n'est pas impliqué dans la gestion des variables de session, c'est un concept purement PHP.

En fait, je viens de voir dans le 'Gestionnaire des tâches' que N fenêtres IE == N threads IEXPLORE.EXE, alors que N fenêtres FF == 1 thread firefox.exe ... C'est donc le choix respectif de gestion des threads qui explique la différence.

Rien à voir.

J'explique :
1) les variables de sessions sont stockées dans des fichiers dans le répertoire temporaire de php (sur le serveur, donc)
2) une fois une session initialisée (par php), php va renvoyer automatiquement un cookie de session au client (le fameux PHPSESSID, encore qu'on peut spécifier un nom différent).
3) le client fait ce qu'il fait avec tout cookie : il le copie méticuleusement dans chaque requète qu'il envoie au serveur
4) du coup, lorsque le client accède à une autre page un peu plus tard, PHP récupère la valeur du cookie, et retrouve le fichier associé à l'identifiant de session.

La persistence des sessions entre fenetres ne dépend donc que d'une seule chose : est-ce que le navigateur a un gestionnaire de cookie séparé pour chaque fenêtre ou non (oui pour IE (enfin ça dépend de comment tu ouvres les nouvelles fenetres en fait), non pour firefox).

Une autre facteur entre en jeu également : le nombre de clients du serveur. Pour ne pas pourrir le répertoire temporaire, le nombre de fichiers de sessions simultanées est limité dans le fichier de conf de php. Lorsque toutes les sessions sont utilisées, une nouvelle session force la destruction d'une ancienne, sélectionnée par LRU.

« Dream is destiny »

20

Le 17/03/2006 à 17:44

La persistence des sessions entre fenetres ne dépend donc que d'une seule chose : est-ce que le navigateur a un gestionnaire de cookie séparé pour chaque fenêtre ou non (oui pour IE (enfin ça dépend de comment tu ouvres les nouvelles fenetres en fait), non pour firefox).

Je vais même être plus précis que toi : "est-ce que le navigateur a un gestionnaire de cookie de session séparé".

21

Le 27/03/2006 à 03:38

Bon, le problème a été résolu, mais sinon il me semble qu'il y a une autre solution. Si je me souviens bien (j'ai arrêté de faire du PHP peut après que les sessions soient apparues, donc peut-être me trompé-je), on peut soit transmettre l'information de session par des cookies, soit par une variable GET (du genre blah.php?a=b&c=d&PHPSESSID=...). Dans le second cas, les informations de session ne sont donc transmises que lorsque l'utilisateur clique sur un lien du site sur lequel il est identifié. Ainsi, si l'utilisateur ferme toutes les fenêtres du dit site, il n'est pas vraiment délogué vu que la session existe toujours sur le serveur, mais les informations de session n'existent plus chez le client, donc c'est tout comme si il était délogué.

I'm on a boat motherfucker, don't you ever forget

22

Le 27/03/2006 à 08:40

Voui, c'est effectivement une solution.

23

Le 27/03/2006 à 09:42

Ah oui, passer le PHPSESSID d'une page à l'autre (ou d'une page index.php à elle-même dans mon cas et celui de Nil) me semble être une excellente solution

!
Surtout que, à première vue, son implémentation ne me paraît vraiment pas compliquée (mais bon, comme d'habitude, c'est toujours quand on se décide enfin à implémenter pour de vrai quelque chose que l'on tombe sur des difficultés auxquelles on n'avait pas pensé

).

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

24

Le 27/03/2006 à 10:03

Ethaniel :
Ah oui, passer le PHPSESSID d'une page à l'autre (ou d'une page index.php à elle-même dans mon cas et celui de Nil) me semble être une excellente solution !
Surtout que, à première vue, son implémentation ne me paraît vraiment pas compliquée (mais bon, comme d'habitude, c'est toujours quand on se décide enfin à implémenter pour de vrai quelque chose que l'on tombe sur des difficultés auxquelles on n'avait pas pensé ).

Ben si je ne m'abuse, il y a une fonction de PHP qui te fait ça de manière transparente. Mais ptet que je m'abuse

I'm on a boat motherfucker, don't you ever forget

25

Le 27/03/2006 à 10:15

J'ai vérifié, on peut le faire soit de manière transparente, soit à la main.

Source : htp://php.net/session

Passer l'identifiant de session (session ID)

Il y a deux méthodes de propagation de l'identifiant de session :

- Cookies
- Par URL

Le module de session supporte les deux méthodes. Les cookies sont optimaux, mais comme ils ne sont pas sûrs (tous les internautes ne les acceptent pas), ils ne sont pas fiables. La seconde méthode place l'identifiant de session directement dans les URL.

PHP est capable de faire cela de manière transparente, lorsqu'il est compilé avec l'option --enable-trans-sid. Si vous activez cette option, les URL relatives seront modifiées pour contenir l'identifiant de session automatiquement. Alternativement, vous pouvez utiliser la constante SID, qui est définie, si le client n'a pas envoyé le cookie approprié. SID est soit de la forme session_name=session_id ou une chaîne vide.

Note : L'option arg_separator.output de php.ini vous permet de personnaliser le séparateur d'arguments. Pour être complètement en accord avec les spécifications XHTML, spécifiez & ici.

Alternativement, vous pouvez utiliser la constante SID qui est définie si la session a commencé. Si le client n'envoie pas un cookie de session approprié, il aura la forme session_name=session_id. Sinon, il vaudra une chaîne vide. Ainsi, vous pouvez dans tous les cas l'inclure dans l'URL.

L'exemple suivant vous montre comment enregistrer une variable et comment réaliser un lien correct avec une autre page, avec SID.

Exemple 3. Compter le nombre de passages d'un utilisateur sur une page
<?php
if (!session_is_registered('compteur')) {
   session_register('compteur');
   $compteur = 1;
} else {
   $compteur++;
}
?>

<p>
Bonjour visiteur, vous avez vu cette page <?php echo $compteur; ?> fois.
</p>

<p>
Pour continuer, <a href="nextpage.php?<?php echo strip_tags(SID); ?>">cliquez ici</a>.
</p>
La fonction strip_tags() est utilisée lors de l'affichage du SID dans le but de contrer les attaques XSS.

L'affichage du SID, comme montré dans l'exemple ci-dessus, n'est pas nécessaire si --enable-trans-sid a été utilisé pour compiler PHP.

Note : Les URL non-relatives sont considérées comme externes au site, et ne recevront pas le SID, car c'est une fuite d'informations vers un autre site (envoi d'informations importantes).

I'm on a boat motherfucker, don't you ever forget

26

Le 27/03/2006 à 13:28

OK, j'en prends note. Mais pour mon utilisation perso :

PHP est capable de faire cela de manière transparente, lorsqu'il est compilé avec l'option --enable-trans-sid.

Et comme je veux que ce que je fais fonctionne également si je le stocke sur Free, et comme je n'ai pas la possibilité de choisir les options compilées, je fais comme si elles ne l'étaient pas, ça m'évite les mauvaises surprises du genre 'ça marche chez moi mais pas sur Free' ...

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

27

Le 27/03/2006 à 16:47

phpinfo();

I'm on a boat motherfucker, don't you ever forget

28

Le 28/03/2006 à 08:31

Mais de toute façon le navigateur stocke les URL dans l'historique, donc est-ce que ça résout vraiment le problème ?

« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

29

Le 28/03/2006 à 14:54

Bah, il suffit d'envoyer le PHPSESSID en POST et non en GET, ça fonctionne tout aussi bien.

Je ne suis pas développeur Java : je suis artiste Java.
Ce que l’on conçoit bien s’énonce clairement, / Et le code pour l’écrire arrive aisément.
Hâtez-vous lentement ; toujours, avec méthode, / Vingt fois dans l’IDE travaillez votre code.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
You don't use science to show that you're right, you use science to become right.

30

Le 28/03/2006 à 18:48

Sally :
Mais de toute façon le navigateur stocke les URL dans l'historique, donc est-ce que ça résout vraiment le problème ?

Ben y a pas vraiment de solution complètement sécurisée à ce problème, de toute façon ... Cette solution ne protège pas des utilisateurs malicieux, mais permet au moins qu'une personne honnête qui se loggue ne se retrouve pas sur la session de qqun d'autre.

I'm on a boat motherfucker, don't you ever forget