Discussion :

[riete]

Si session_save_path n'a pas de valeur définit en consultant php_info() ou en appelant la fonction, ou sont stockés les fichiers de session alors, dans la doc je ne vois rien ?

Merci

[julp]

Ça fonctionne comme upload_tmp_dir : si rien ne lui est spécifié, PHP tentera de déterminer et utiliser le répertoire temporaire système (/tmp sous Unixoïde et C:\WINDOWS\Temp sous Windows, si je ne m'abuse).

[riete]

Je suis effectivement sous Unix/OSX, je suis allé voir dans /tmp, mais il n'y a rien qui ressemble à des fichiers de SESSION (il n'y a presque rien d'ailleurs).

Comment se nomment les fichiers SESSION afin que je puisse les rechercher dans l'arborescence?

[julp]

sess_<sid>

Mais :

• ce n'est valable que pour le gestionnaire par défaut (fichiers)
• il faut toujours regarder un phpinfo situé au même endroit que son application
• également regarder si vos scripts ne le redéfinissent pas déjà via ini_set
• pas d'erreur à ce niveau ?

[riete]

merci pour l'info. Avec une bonne command find depuis /, j'ai trouvé !
Pour ce que cela interesse sous OSX PHP stocke par défaut les SESSION dans /private/var/tmp.

Une paranthèse: Je me demande s'il ne serait pas interessant de mettre un script dans la crontab afin de mettre en place des procédures de sécu, votre avis ?

[julp]

A quelle fin précisément ? Par rapport à leur expiration ?

C'est possible mais à voir suivant les besoins et le contexte.

[riete]

Je pense qu'il y a pas mal de possibilités (que je ne suis sûrement pas le premier à envisager d'ailleurs) à exploiter. La date d'expiration en est une, je pensais aussi au contenu, en fonction du type des fonctionalités du site ou elles sont hébergés leur heure de création etc ...
On pourrait aussi penser à la géolocalisation de l'IP du créateur, vous pourriez me dire à juste titre pourquoi de ne pas le tester à la création?

Voici quelques idées en vrac sans trop me casser la tête.

Mais en tous cas ma question est solutionner merci.

[julp]

Quel rapport avec cron ? Comment un tel processus va-t-il pouvoir vérifier les données d'une session (à commencer par les IP) si justement il n'y a pas de client (HTTP) associé ? Ce genre de contrôle doit être effectué au démarrage de la session (sa récupération pour être précis).

Tout le monde n'utilise pas non plus une IP statique : une limitation sur l'IP n'est-il pas plus contraignant ?

Et puis ça dépend de l'environnement (mutualisé/dédié).

cron, à la rigueur, c'est bon pour assurer l'expiration de la session. Mais PHP intègre, certes bien à lui, un GC à ce niveau.

Le contenu des sessions ? Impossible à vérifier, peu importe le moyen et le gestionnaire, pour des sessions forgées (mutualisé avec espace partagé par exemple) ou si vous êtes compromis d'une manière ou d'une autre. Et puis un tel procédé aurait probablement un coût assez important.

[riete]

Quel rapport avec cron ? Comment un tel processus va-t-il pouvoir vérifier les données d'une session (à commencer par les IP) si justement il n'y a pas de client (HTTP) associé ? Ce genre de contrôle doit être effectué au démarrage de la session (sa récupération pour être précis).

Tout le monde n'utilise pas non plus une IP statique : une limitation sur l'IP n'est-il pas plus contraignant ?

La crontab lance un script qui effectuerait divers opérations de contrôle sur l'ensemble des sessions en cours. Comme je le disais dans mon précédent message, il est surement plus efficace de faire le ctrl de l'IP à la création de la SESSION.
Mais effectivement l'IP dynamique peut embrouiller les cartes.

Je vais peut être dire une bétise, mais tant pis je me lance
Si à la création de la session on y stocke l'IP, on a une association possible SESSIONID et IP. Le client se reconnecte plus tard depuis une autre lieu. L'association IP/ID est contrôlée mais ne correspond plus. Donc risque de subtilisation de session. Je me trompe ?

Et puis ça dépend de l'environnement (mutualisé/dédié).

cron, à la rigueur, c'est bon pour assurer l'expiration de la session. Mais PHP intègre, certes bien à lui, un GC à ce niveau.

Je suis en dédié.

Le contenu des sessions ? Impossible à vérifier, peu importe le moyen et le gestionnaire, pour des sessions forgées (mutualisé avec espace partagé par exemple) ou si vous êtes compromis d'une manière ou d'une autre. Et puis un tel procédé aurait probablement un coût assez important.

J'avoue ne pas bien comprendre cette réflexion. Le contenu d'une SESSION me parait tout à fait lisible et gérable . "Sessions forgés" je ne comprends pas et le coût je ne vois pas.

[julp]

Si à la création de la session on y stocke l'IP, on a une association possible SESSIONID et IP. Le client se reconnecte plus tard depuis une autre lieu. L'association IP/ID est contrôlée mais ne correspond plus. Donc risque de subtilisation de session. Je me trompe ?

Non.

J'avoue ne pas bien comprendre cette réflexion. Le contenu d'une SESSION me parait tout à fait lisible et gérable . "Sessions forgés" je ne comprends pas et le coût je ne vois pas.

Ben, justement. Un exemple de "forger une session" en milieu mutualisé avec espace partagé. Pour le coût, je parle bien en terme de ressources système. Mais vous pensiez peut être à autre chose en évoquant le contenu ?

[RunCodePhp]

Salut à tous

Topic très intéressant

Si on se trouve dans un espace partagé, ne serait il pas judicieux de créer un répertoire dédié aux sessions dans son propre espace, en dehors du wwwROOT.

Voir mieux, stocker les sessions dans une BDD ?

Pour ce qui est de vérifier une certaine concordance entre l'IP/SESSION_ID, je trouve que ce mécanisme risque d'être casse gueule.
Il me semble pas qu'il y ait un moyen rapide et surtout fiable à 100% garantissant d'avoir la bonne IP. Du moins c'est ce que je pense.
On rencontre le même problème pour les e-mail.

Le plus sage il me semble c'est de faire attention à ce qu'on stocke dans les sessions, d'éviter des données trop sensibles (comme des N° de carte bleu).

Après ça, si un site véhicule des données sensibles, dans ces condition il serait (peut être) mieux de faire ces opérations dans un espace plus verrouillé/sécurisé.
Genre protection par .htaccess/.htpasswd, rajouter du SSL, voir d'autres mécanismes garantissant la personne qui y accède et l'intégrité des données qui circulent.
Ici, même un vol de session ne serait pas suffisant pour accéder à ces données.

Si les données sont hyper sensibles, alors là il faut au minimum être soit même hyper compétant, ou alors on fait appel a des personnes qualifiées.

S'il y a un vol de session dans un espace public, quelque part l'incident est plus que mineur, rien d'important, le pirate ne fait que perdre son temps.

[riete]

Ben, justement. Un exemple de "forger une session" en milieu mutualisé avec espace partagé. Pour le coût, je parle bien en terme de ressources système. Mais vous pensiez peut être à autre chose en évoquant le contenu ?

Ok message bien reçu, je comprends bien le coup de la forge .
Pour les contenu je parlais effectivement du contenu de la session et non du contenu système.

Salut à tous

Topic très intéressant

Si on se trouve dans un espace partagé, ne serait il pas judicieux de créer un répertoire dédié aux sessions dans son propre espace, en dehors du wwwROOT.

Voir mieux, stocker les sessions dans une BDD ?

Stockées dans une BDD ou pas les transactions client persistent. Quel est donc l'interêt?

Pour ce qui est de vérifier une certaine concordance entre l'IP/SESSION_ID, je trouve que ce mécanisme risque d'être casse gueule.
Il me semble pas qu'il y ait un moyen rapide et surtout fiable à 100% garantissant d'avoir la bonne IP. Du moins c'est ce que je pense.
On rencontre le même problème pour les e-mail.

Je suis assez d'accord avec toi, mais cela dépends comme d'habitude de l'environnement dans lequel tu travail. Il n'y a pas de solution universelle, c'est d'ailleurs pour cela que nous avons du boulot. Sinon, une belle boite en carton acheté à la boutique du Chinois d'en bas et l'affaire serait jouée

Le plus sage il me semble c'est de faire attention à ce qu'on stocke dans les sessions, d'éviter des données trop sensibles (comme des N° de carte bleu).

Après ça, si un site véhicule des données sensibles, dans ces condition il serait (peut être) mieux de faire ces opérations dans un espace plus verrouillé/sécurisé.
Genre protection par .htaccess/.htpasswd, rajouter du SSL, voir d'autres mécanismes garantissant la personne qui y accède et l'intégrité des données qui circulent.
Ici, même un vol de session ne serait pas suffisant pour accéder à ces données.

Si les données sont hyper sensibles, alors là il faut au minimum être soit même hyper compétant, ou alors on fait appel a des personnes qualifiées.

S'il y a un vol de session dans un espace public, quelque part l'incident est plus que mineur, rien d'important, le pirate ne fait que perdre son temps.

Evidement, qui dit données sensible dit SSL, tu en doutais ?

[RunCodePhp]

Stockées dans une BDD ou pas les transactions client persistent. Quel est donc l'interêt?

C'était en rapport aux espaces partagés.
J'ai déjà lu à plusieurs reprises dans des forums que certains ont des problèmes de sessions "volés" sans l'ombre d'une tentative de piratage.

Le problème vient d'un hébergeur ayant donc plusieurs clients (espace mutualisé) qui utilisent les même CMS, et comme les nom des sessions sont les mêmes et stockés (apparemment) dans le même répertoire (par défaut), il arrive que certain se retrouvent avec des données qui ne sont pas les leurs, mais ceux d'un autre client.
Ca fait très bizarre quand ça arrive, ça l'est d'autant plus quand c'est une boutique en ligne

Le fait de créer un répertoire dans son propre espace que leur a alloué l'hébergeur ou les stocker dans une BDD suffit pour résoudre ce problème.

Evidement, qui dit données sensible dit SSL, tu en doutais ?

Pour ma part non
Mais il existe une floppée de boutique en ligne qui non seulement récupèrent les N° de cartes bleu sans le moindre élément de sécurité, mais en plus les stocks dans leur BDD, en clair, tel quels.
C'est effrayant !!!

Le pire, c'est quand on leur explique qu'il vaut mieux faire ces transactions bancaires avec justement une banque ou autre paypal, ne serait ce que pour leur responsabilité, ils disent que c'est trop cher, ou alors que c'est trop compliqué à mettre en place.
Bonjours l'angoisse ...

[riete]

C'était en rapport aux espaces partagés.
J'ai déjà lu à plusieurs reprises dans des forums que certains ont des problèmes de sessions "volés" sans l'ombre d'une tentative de piratage.

Le problème vient d'un hébergeur ayant donc plusieurs clients (espace mutualisé) qui utilisent les même CMS, et comme les nom des sessions sont les mêmes et stockés (apparemment) dans le même répertoire (par défaut), il arrive que certain se retrouvent avec des données qui ne sont pas les leurs, mais ceux d'un autre client.
Ca fait très bizarre quand ça arrive, ça l'est d'autant plus quand c'est une boutique en ligne
Le fait de créer un répertoire dans son propre espace que leur a alloué l'hébergeur ou les stocker dans une BDD suffit pour résoudre ce problème.

Merci pour cette info, je ne connaissais pas ce genre de problèmes. D'ou l'intéret de partager nos connaissances

Pour ma part non
Mais il existe une floppée de boutique en ligne qui non seulement récupèrent les N° de cartes bleu sans le moindre élément de sécurité, mais en plus les stocks dans leur BDD, en clair, tel quels.
C'est effrayant !!!

Le pire, c'est quand on leur explique qu'il vaut mieux faire ces transactions bancaires avec justement une banque ou autre paypal, ne serait ce que pour leur responsabilité, ils disent que c'est trop cher, ou alors que c'est trop compliqué à mettre en place.
Bonjours l'angoisse ...

Des noms, des noms !!! je m'en doutais un peu, mais comme je ne pratique pas le ecommerce... C'est vraiment dangereux ce type de comportement.
@+

[RunCodePhp]

Code :

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

Des noms, des noms !!!

Bah non, j'fais pas dans la délation.



N'insistez pas