Les sessions

"maintenant que qu'on ne peut plus enregistrer un tableau dans une variable de session". J'ai PHP 5.4.0 (donc la toute dernière) et ça marche sans aucun problème. Pourquoi ne pourrait-on plus ? On peut tout stocker dans les sessions : des objets, des array à 200 niveau, tous les types de variables. Au contraire, c'est dans les anciennes versions que la serialisation se faisait mal. Aujourd'hui PHP gère tout sans que tu n'aies rien à faire.

le session_id est chargé en RAM à chaque script. Et les variables sont stocké dans un fichier (dans le dossier de sessions dont le chemin est paramétrable) et le nom de ce fichier est le session_id

Note : on peut également configurer PHP pour transmettre le session_id dans une variable GET plutôt qu'on cookie mais c'est tout de même moins adapté.

re salut,

Forcer l'utilisation des cookies pour l'utilisation des sessions limite le risque
de vol de session.
Mais si on fait passer l'id de la session dans des variables $_POST au lieu de la faire passer
dans l'url de cette manière :

if ( isset( $_POST['session_id'] ) == true )
{
  session_id( $_POST['session_id'] ) ;
  session_start() ;
  session_regenerate_id() ;
}
else
{
  session_start() ;
  session_regenerate_id() ;
}

<form action="" method="post">
<input type="hidden" name="session_id" value="<?php echo session_id() ; ?>" />
<input type="submit" value="Envoyer" />
</form>

est-ce que le risque est de même niveau qu'avec l'affichage de l'id de session dans l'url ?
Modifié par perfectionniste (10 Apr 2012 - 07:17)

Les sessions sont d'une part, stocké chez le client, et d'autre part, stocké sur le serveur.

GET ou POST, niveau sécurité, c'est la même chose.

Que veux tu faire exactement, car ... c'est très flou pour moi.

Bonjour Super_baloo8,

Les risques en transmettant les identifiants de la session dans l'url sont les suivants :

- Ils deviennent visibles dans la barre d'adresse. Dans un lieu public, n'importe qui peut passer derrière et prendre discrètement une photo de l'écran.
- Ils sont stockés dans l'historique du navigateur
- Ils sont transmis dans le référant.
-L'utilisateur non averti peut compromettre lui-même ses identifiants de session en copiant-collant l'adresse de la page qu'il consulte sur un forum public.

Avec la méthode POST, c'est déjà beaucoup moins risqué, mais j'ai un peu de mal à imaginer une application ou un site Web sécurisé qui n'utiliserait que la méthode POST pour naviguer. perfectionniste, peux-tu donner un peu plus de détails sur ton objectif?

merci jb_gfx pour ton aide !

perfectionniste a écrit :
Finalement ma question c'est pour savoir si c'est facile pour un pirate d'accéder aux variables transmises avec la méthode post car j'entends que c'est pareil que la méthode get, pourtant on transmet bien un mot de passe à la base de données avec la méthode post pour l'authentification...

Peut importe, si le pirate veut quelque chose, il l'aura ne te fait pas de soucis là dessus.

Sinon, en restant un peu plus sérieux, une discussion intéressante retrouvée sur ce forum

Je rejoins l'avis de jb_gfx, le SSl sera "parfait", mais à quel coût ?

Le SSL n'est pas gratuit, au mieux, il est mutualisé, mais à quel performance ?

Est-ce que ce que tu souhaites mettre en place mérite un traitement avec SSL ?

Si, c'est pour un site avec un forum ... l'intérêt est très limité, regarde sur ce forum, pas d'accès SSL en place pour ça

------------

@Tony, en effet, je n'avais pas penser à l'historique +1

Mais pour revenir à l'ID de la session, normalement, on s'en fout, personnellement, sur mes sites qui demandent une identification, et une session, je m'en réfère à 2 autres cookies stockés chez le client, un qui contient l'identifiant de l'utilisateur + un autre qui contient le mot de passe hashé, où je compare en permanence les 2.

Donc, pour permettre de faire un vol de session, il faut qu'il ait, le numéro de session + les 2 autres cookies bien renseignés.

Donc, s'il a les cookies du client, bon bah là, je ne peux rien pour l'utilisateur (si ce n'est une restriction sur l'adresse IP, mais c'est toujours falsifiable avec un peu de spoofing, et donc faut trouver autre chose ... mais bon ... je ne fait pas de site bancaire, et avec des si, on refait le monde)

Super_baloo8 pour un site e commerce ?

Du moment que tu demandes au client de fournir ses informations de carte de crédit ou de carte bancaire sur ton propre site de e-commerce, le SSL est obligatoire pour des raisons évidentes de sécurité. Le marchand a aussi l'obligation de se conformer à la norme Payment Card Industry Data Security Standard (PCI DSS) qui porte sur la sécurisation des données de détenteurs de cartes de crédit. Pour plus de détails (site Québécois).

La présence du https sur un site permet aussi de rassurer le client.

Il existe cependant des fournisseurs de passerelle de paiement en ligne qui offrent un mode de paiement avec une redirection. Le client rempli le panier sur le site du marchand (http sans ssl) et il est ensuite redirigé vers un site externe sécurisé (https - ssl - pci dss) pour effectuer son paiement en ligne. On peut penser à Paypal, mais il est loin d'être le seul à offrir cette possibilité. J'en connais et utilise quelques-uns au Québec.
Modifié par Tony Monast (11 Apr 2012 - 13:15)