Discussion :

[Kioob]

Un des seuls avantages d'OVH c'est leur guide... ce serait bien de le consulter... http://guides.ovh.com/Php5ChezOvh/

Toutefois, même s'ils proposent PHP 5, il s'agira certainement de PHP 5.0 pas 5.1 (à vérifier toutefois).

[psychoBob]

Bon, après 48 allez retour de la main gauche, j'ai trouvé ça chez ovh :

Pour utiliser Php5? chez ovh, il suffit de transferer via ftp vos scripts avec l'extention
php5. Par exemple:

mon_scripts.php5

Donc je peux utiliser php5 mais qui me dit que ce sera la bonne extension, d'autant plus que le message d'erreur ne s'affiche pas ?
Ou alors je fais un script, mais est-ce que ça va pas tout faire foirer.

Et si ça se trouve en passant mes pages en php5, mes scripts vont foirer. ça m'étonnerait ce sont des scripts "normaux", mais bon...

Vous en pensez quoi ?

[psychoBob]

Un des seuls avantages d'OVH c'est leur guide... ce serait bien de le consulter... http://guides.ovh.com/Php5ChezOvh/

Toutefois, même s'ils proposent PHP 5, il s'agira certainement de PHP 5.0 pas 5.1 (à vérifier toutefois).

on a posté en même temps, Kioob.


Bon justement, je vérifie comment par exemple ? Je vais pas leur envoyer un mail que pour ça quand même.

[Kioob]

bah tu te fais un script avec l'extension ".php5" et tu y colles ton phpinfo();

[psychoBob]

J'y avais pensé entre temps ! (si c'est vrai)

Mais merci de me l'avoir dit.
J'ai la version 7.09 eheh.


Ok, ok 5.0.4, donc ça doit être bon, oui ?


**edit**
ça fait quoi par curiosité si certaines page ont l'extension php (donc font appel à php 4.02) et d'autres php5 dont bossent avec 5.0.4 ?

[Swoög]

Ok, ok 5.0.4, donc ça doit être bon, oui ?

non : 5.0.4 < 5.1

ça fait quoi par curiosité si certaines page ont l'extension php (donc font appel à php 4.02) et d'autres php5 dont bossent avec 5.0.4 ?

il est fort probable que les sessions ne puissent passer de l'un à l'autre...

[psychoBob]

Code :

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

1
2
3
psychoBob a écrit :
Ok, ok 5.0.4, donc ça doit être bon, oui ?
non : 5.0.4 < 5.1 :wink:

Ouaip c'est juste.
Donc j'en ai réellement plein le ionf.

Je dois me morfler un script pour remplacer le paramètre delete_old_session ?
Quelqu'un en a un tout fait ? Je suis sur que oui...

[Swoög]

pourquoi ne pas simplementlaisser tomber le regenerate_id ?
c'est pas vraiment une protection, comme je te l'ai expliqué... c'est à double tranchant....

si on pique la session avant que le session_id ait changé, surtout si les anciens fichiers sont supprimés, la session n'appartient plus qu'à celui qui l'a volée...

[psychoBob]

Parce que j'ai lu sur cette page, qu'il ne faut jamais utiliser les sessions avec seulement sessions_start().

J'ai bidouillé un petit script, mais c'est insuffisant.

Donc comment faire pour sécuriser mes sessions, sans tomber dans le ssl (c'est pour un forum) ?

[Swoög]

déjà, rien que stocker l'ip du visiteur ($_SERVER['REMOTE_ADDR']) et la vérifier sera déjà important...

ensuite la signateur du navigateur ($_SERVER['HTTP_USER_AGENT'])...

enfin vérifier le referer (configuration de PHP)

je pense déjà que ceci devrait être suffisant...

après tu peux éventuellement rajouter des infos captées par JavaScript, style : résolution de l'écran et Système d'exploitation

ça commence déjà à être assez important...

pour les vérifs :

Code :

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

1
2
3
4
<?php
session_start();
if(!__session__valide()) session_write_close();
?>

[Kioob]

je pense déjà que ceci devrait être suffisant...

ce n'est pas suffisant, c'est trop. Rien qu'avec le test IP tu perds pas mal d'utilisateurs légitimes.

[Swoög]

ce n'est pas suffisant, c'est trop. Rien qu'avec le test IP tu perds pas mal d'utilisateurs légitimes.

Pourquoi des utilisateurs légitimes ?
l'IP n'est pas censée changer...

en plus, l'IP seule, il y a un risque pour ceux qui passent par un proxy

[psychoBob]

Si on en a parlé dans tous les derniers posts que j'ai posté ces derniers jours, sur les ip dans les sessions et le vol de celles-ci :

Les ip c'est nul, par exemple il y a des proxys et surtout les visiteurs d'aol dont les ip changent constamment durant la connexion.

Sur le lien que j'ai indiqué dans le message juste avant, ils disent que le HTTP_USER_AGENT est mauvais aussi.

Maintenant tu dis qu'en plus session_regenerate_id() est foireux aussi.

Donc je n'ai plus qu'à me reposer sur mon système de déconnexion en cas de vol de session. Mais c'est loin d'être parfait quand même... Personnes n'a la bonne solution dirait-on.

[Kioob]

Il n'y a pas de "bonne solution universelle". Même ton système de deconnexion est forcément foireux, puisqu'il n'existe aucun moyen de savoir s'il s'agit du vrai utilisateur ou non.

Tout ce que tu peux faire, c'est limiter les risques de vol, et c'est en cela que session_regenerate_id() est interessant. Mais ce n'est pas la parade ultime.
L'idéal serait également d'éduquer les utilisateurs pour qu'ils cliquent systématiquement sur "se déconnecter" quand ils quittent le site... mais même ça, ça ne règlera pas les risques de vol durant la navigation.

[psychoBob]

Même ton système de deconnexion est forcément foireux, puisqu'il n'existe aucun moyen de savoir s'il s'agit du vrai utilisateur ou non.

Oui c'est vrai, mais ça déconnecte les deux de toute façon (ok pas dans tous les cas mais bon). Il vaut mieux déconnecter le membre sans qu'il pige pourquoi plutot que de laisser le pirate voler la session.

Tout ce que tu peux faire, c'est limiter les risques de vol, et c'est en cela que session_regenerate_id() est interessant. Mais ce n'est pas la parade ultime.

Et bien mettez-vous d'accord, toi et Swoög, ce sera intéressant. Parce que Swoög à l'air de dire que c'est autant un problème qu'autre chose.

L'idéal serait également d'éduquer les utilisateurs pour qu'ils cliquent systématiquement sur "se déconnecter" quand ils quittent le site... mais même ça, ça ne règlera pas les risques de vol durant la navigation.

L'éducation c'est la clef de tout. Mais plus ça va plus elle décroit.

[Swoög]

Et bien mettez-vous d'accord, toi et Swoög, ce sera intéressant. Parce que Swoög à l'air de dire que c'est autant un problème qu'autre chose.

Le regenerate_id est "pas mal" SI tu supprimes les fichiers de sessions périmés en même temps, mais ça reste à double tranchant...

[psychoBob]

Le regenerate_id est "pas mal" SI tu supprimes les fichiers de sessions périmés en même temps, mais ça reste à double tranchant...

J'adore le SI... ça fait jamais que 48H qu'on me l'a appris et que j'y arrive pas...

Qui confirme ce que dit notre ami Swoög sur l'effet à double tranchant du regenerate_session_id (true) ?

[Kioob]

avec session_regenerate_id() : en cas de vol de session (qui je le rapelle, est plus difficile lorsque l'ID change régulièrement) cela déconnecte l'utilisateur légitime mais laisse le pirate libre de faire ce qu'il veut...

sans session_regenerate_id() : en cas de vol de session (qui devient alors plus "facile") l'utilisateur légitime ne s'en rend pas compte, et le pirate est libre de faire ce qu'il veut...

Bref, pour ma part je préfère le premier cas : ce n'est pas le saint graal, n'ajoute aucun problème de sécurité, et au contraire diminue les risques.

Mais bien sûr, comme répété 36 fois, ceci est vraiment _uniquement_ si l'ancienne session est supprimée.
Et pour répondre à ta question, un "unlink( $session_save_path .'/'. $old_sid );" devrait suffir sur une configuration "standard". Je te laisse trouver comment remplir les variables hein, cherches un peu après tout

[psychoBob]

Bon je vais voir ta soluce pour le principe, Kioob, mais j'ai bien l'impression que mon script fait aussi bien que ce session_regenerate_id.
Il ne complique certe pas le vol de session, mais au moins il déconnecte le pirate (sauf si celui-ci vole la session pile lorsque le membre identifié cesse d'utiliser le site, c'est quand même pas de pot).
En plus dans ma session y'a que dalle, je remplace l'id du membre par un numéro provisoire.

Vous en pensez-quoi ?

[Kioob]

Bon je vais voir ta soluce pour le principe, Kioob, mais j'ai bien l'impression que mon script fait aussi bien que ce session_regenerate_id.
Il ne complique certe pas le vol de session, mais au moins il déconnecte le pirate (sauf si celui-ci vole la session pile lorsque le membre identifié cesse d'utiliser le site, c'est quand même pas de pot).
En plus dans ma session y'a que dalle, je remplace l'id du membre par un numéro provisoire.

Vous en pensez-quoi ?

Je n'ai pas lu ton script, et n'ai pas trop de temps à y consacrer. Mais sur le principe à moins de faire comme le session_regenerate_id (à savoir envoyer par cookie à chaque hit une clé aléatoire), je ne vois pas comment ça pourrait marcher, vu que le seul truc de persistant ce sont les cookies et que justement, un cookie ça se vole... On tourne en rond quoi...