Bonjour,
 
J'ai fait un simple système d'authentification avec session.
Si l'authentification réussi, je mets la valeur '1' dans $_SESSION['auth'], et au débutde chaque page je vérifie si $_SESSION['auth'] == '1'
La sécurité est-elle suffisante ? Quelqu'un pourrait-il changer la valeur de la variable de session ?
 
Merci

http://phpsec.org/projects/guide/4.html

donc je dois mettre le login et le mdp dans une variable de session, et je verifie s'ils correspondent à chaque page ?

A priori la gestion de session semble sure.

j'ai des doutes après avoir lu le texte de sielfried

Oui, mais lis bien son article.
Déjà, passer son numéro de session en GET dans son URL est une hérésie et c'est sans intérêt, les variables de session étant superglobales.
Ensuite, l'utilisation de sessions te permet de t'affranchir des cookies, alors que l'exemple en fait mention. Comme pas mal de navigateurs les limitent ou les bloquent, autant ne pas les utiliser.
Quant à la récupération des mots de passe sur une BdD, là aussi il convient de prendre les précautions nécessaires et ne pas autoriser n'importe qui à y accéder.
 
Avec les protections habituelles (failles include et require par exemple), pas de valeurs passées en GET (surtout au niveau de l'ID Session) et pas de cookies relatif à la session sur la machine client, tu limites considérablement les risques.

il y a deux informations contradictoires dans ton message
> l'utilisation de sessions te permet de t'affranchir des cookies
> passer son numéro de session en GET dans son URL est une hérésie
 
la stratégie de php est de placer un cookie de session quand c'est possible, sinon on passe l'id de session dans l'URL

il n'est pas nécessaire de faire passer en GET, puisqu'on a le tableau $_SESSION

PHP gère ça en toute transparence

mcjoedassin, il n'y a rien de contradictoire : on voit de nombreux sites avec une ID Session écrite noir sur blanc dans l'URL alors qu'il est parfaitement envisageable de s'en passer.
 
Pour les cookies, il faut tenir compte du nombre croissant d'utilisateurs qui les refusent systématiquement. Autant faire comme si ils n'étaient pas acceptés.
 
Bref, je ne vois aucune contradiction dans mes propos.

désolé de m'être mal exprimé ...
en fait le client DOIT envoyer à chaque fois son numéro de session pour  
que le serveur s'identifie... et pour ce faire, il y a deux façons :
dans l'URL ou à l'aide d'un cookie...
 
ce qui fait que tu ne peux dénigrer ces deux solutions d'un seul bloc ...

que le serveur L'identifie, sorry

Mais c'est ton serveur qui gère ton ID de session, par le poste client.
Je fais régulièrement des sites avec identifications et gestion de session, sans cookies et à aucun moment l'ID session n'apparaît dans l'URL.
 
Effectivement, pour éviter à un utilisateur de s'identifier à chaque passage, il faut nécessairement envoyer des infos au serveur et je pense que tes propos allaient dans ce sens. Mais cette méthode a des failles.
Question de goût, mais je préfère développer des sites avec identification uniquement par session, ce qui implique que l'utilisateur doivent s'identifier à nouveau si il a fermé son navigateur. De cette façon, pas de cookies, pas d'ID dans l'URL.

ah d'accord, en fait tu n'utilises pas vraiment les sessions, c'est ça ? je veux dire à chaque fois que le client veut voir une page il est obligé de s'identifier, c'est ça ?

ou disons que tu fais à chaque fois un POST avec dedans le login&password de l'utilisateur ?

Pas du tout. Chaque utilisateur qui va sur le site a sa propre session (session_start). Qu'il soit identifié ou non, tant qu'il ne ferme pas son navigateur, son ID session est créé et c'est le serveur qui gère.
L'utilisateur peut s'identifier par exemple pour valider un achat. La session est toujours la même, et une fois identifié, je crée la variable $_SESSION['login'] et $_SESSION['password']. En plus, je récupère dans la base de données le statut relatif à la personne identifiée (administrateur, client, super-administrateur). Je crée une variable $_SESSION['statut'] dans laquelle je place le statut de l'identifié.
Les variables de session étant des superglobales, je n'ai pas besoin de les passer d'une page à l'autre.
Dès que je dois vérifier un droit, comme par exemple l'accès aux pages d'administration, je me contente de tester $_SESSION['statut'] qui a été créé, je le rappelle, une fois le login et le password authentifiés. Donc, pas de d'identification, pas de $_SESSION['statut'] (enfin, une valeur nulle).
Il suffit d'appeler une fonction au début de chacune de tes page pour tester la valeur de $_SESSION['login'].
 
Donc, pas de cookies, rien dans l'URL, tout se gère côté serveur.

donne moi l'adresse d'un de tes sites !

En cours de réalisation et utilisation cette méthode :
http://www.caroline-et-cie.fr
 
L'inscription et l'identification sont opérationnelles, je t'invite à essayer. Accessoirement, si tu trouves une faille quelconque, pense à faire le feedback.

session_start() crée une session (ou restaure celle trouvée sur le serveur, via l'identifiant de session passé dans une requête GET, POST ou par un cookie) (cf http://fr.php.net/manual/fr/functi [...] start.php)

Une fois identifié, quand tu vas sur ton compte, tu peux modifier tes infos. Même méthode : requête sur la base pour récupérer les informations d'un inscrit, je stocke le résultat dans des variables de session.
Pour le formulaire de modification, je me contente de les récupérer.

oh le beau cookie !
 
$nc www.caroline-et-cie.fr 80
GET / HTTP/1.1
Host: www.caroline-et-cie.fr
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 15:34:13 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Set-Cookie: PHPSESSID=9f5154450c5b167229f959d82d4b4e73; path=/
...

Ca, c'est le fonctionne par session : il y a tentative d'écriture de cookie sur le poste client. Si le poste les accepte, OK, c'est écrit. Sinon, pas de soucis, ça continue.
Le site est hébergé sur un serveur mutualisé, je n'ai donc pas accès au php.ini ou sont paramétrés les cookies de session (comme le session.lifetime). Il est évident que ce pour ce site en particulier qui sera hébergé sur un serveur dédié, il n'y aura pas de cookies de session écrits sur le disque client.

l'identification n'est alors valide que pour une page, non ? s'il veut faire un achat, puis un autre, il est obligé de s'identifier deux fois ?

Pas du tout : ton identification est valide jusqu'à ce que tu fermes ton navigateur, ou encore que tu te déconnectes ou bien au-delà du délai défini dans PHP.INI
Et pas besoin d'utiliser des inclusions comme je l'ai fait, la méthode fonctionne avec des pages toutes simples.

explique moi alors comment le serveur c'est à qui il a affaire puisque le client ne lui envoies pas l'id de session ni son login|password ?

Parce que c'est le serveur qui gère : tant que la connexion est existante, c'est-à-dire que les sockets de connexion entre le client et le serveur sont actifs, ta session reste ouverte.

certains proxy partagent cette connexion entre les différents utilisateurs... par ailleurs internet explorer peut créer plusieurs connexions TCP pour charger les pages. Enfin, la connexion TCP reste active 17.6 secondes (temps calculé chez moi).
 
Es tu bien sûr de ce que tu avances ?

Oui, j'ai eu aussi cette réflexion en découvrant la gestion des sessions en PHP, mais cette gestion est complément transparente.
Sur le même site, ma cliente est actuellement en train d'uploader ses articles en utilisant un espace d'administration qui fonctionne de façon similaire : elle s'identifie, et ensuite elle uploade à la chaîne, son identification restant valide tant qu'elle ne ferme pas son navigateurs.

j'imagine qu'elle a les cookies activée ...
 
de toute façon, ton argument est faux, PHP ne ferait pas une telle erreur :
HEAD / HTTP/1.1
Host: www.caroline-et-cie.fr
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 16:13:02 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Set-Cookie: PHPSESSID=942ec49a6d17b3b348297bc4f14b82b3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
 
HEAD / HTTP/1.1
Host: www.caroline-et-cie.fr
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 16:13:13 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Set-Cookie: PHPSESSID=2a9cc1ead63162fc470fedeed2187e12; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
 
HEAD / HTTP/1.1
Host: www.caroline-et-cie.fr
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 16:13:14 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Set-Cookie: PHPSESSID=37c88277280cf7d66e5653662b53188c; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
 
 
trois requetes sur la même connexion, trois cookies différents ...

Vérification faite, il y a bien stockage sur le poste client. Je n'ai pas accès au fichier de configuration du serveur, je ne peux pas modifier ces paramètres, comme le nom de la variable de session. Dès que je passe en serveur dédié, je fais l'essai.

HEAD / HTTP/1.1
Host: www.caroline-et-cie.fr
Cookie: PHPSESSID=123
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 16:15:05 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
 
HEAD / HTTP/1.1
Host: www.caroline-et-cie.fr
 
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2005 16:15:15 GMT
Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.10 FrontPage/5.0.2.2510 mod_perl/1.26
X-Powered-By: PHP/4.3.10
Set-Cookie: PHPSESSID=87e876bb3b4e07ae3ff2f16009ae97db; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
 
deux requetes sur la meme connexion, la premiere avec un cookie, la deuxieme sans le cookie : le serveur tente de placer un autre cookie

oki doki ! tiens moi au courant

 
il y a déjà un path disclosure si tu passes PHPSESSID=# par exemple, tu as
<b>Warning</b>:  session_start(): The session id contains invalid characters, valid characters are only a-z, A-Z and 0-9 in <b>/home/.sites/33/site5/web/index.php</b> on line <b>2</b><br />
<br />
<b>Warning</b>:  session_start(): Cannot send session cache limiter - headers already sent (output started at /home/.sites/33/site5/web/index.php:2)

Merci pour ton info, effectivement il y a bien une écriture et jeme coucherai moins crétin que je ne me suis levé ce matin. Curieux, c'est en contradiction avec pas mal de choses que j'ai pu lire sur le net.
Je vais aller fouiller du côté php.ini