Discussion :

[gloubi]

Voilà, j'ai un petit jeu PHP qui tourne depuis plusieurs moi maintenant avec environ 150 - 200 utilisateurs / jours, mais voilà que cette nuit, j'ai eu droit à la 1er tentative de hack réussie...

Le hack en question, c'est quelqun qui a réussi à se connecter avec le compte d'un autre... Comment il a fait, j'en sais rien, et je cherche encore.

Quiqu'il en soit, je soupsonne évidemment un problème de cookie voir de récupération d'ID de session...

Je me proposais donc d'ajouter la sécurité suivante : je stock en session l'IP de la machine au moment du login, et a chaque rafraichissement de page, je test si $_SESSION['ip'] == $_SERVER['REMOTE_ADDR']

Avant d'implémenter ça, je voudrais avoir vos avis, et surtout, je voudrais m'assurer que (contrairement aux sessions) la variable $_server sera bien remise à jour à chaque rafraichissement de la page (a prioris, je suppose)...

En vous remerciant par avance

[Fladnag]

oui, ca sera mis a jour mais... si ton utilisateur a AOL pour FAI... ou si il passe par un reseau d'entreprise assez important pour avoir plusieurs proxys de sortie, l'adresse IP peut etre différente pour chaque page chargée.

Je te conseille plutot de mettre un timeout sur tes sessions et d'inviter tes utilisateurs a se "deconnecter" proprement. S'ils ne se deconnectent pas, le cookie de session restera actif jusqu'au timeout, et c'est a leur risque et périls si quelqu'un d'autre se connecte sur le site ensuite depuis le meme PC.

Autre source de vol d'ID de session :
* copier / coller de l'url avec l'ID de session dedans (la faute a l'utilisateur)
* faille dans ton site qui permet par Cross Site Scripting de récuperer le cookie contenant l'ID de session (ta faute ET la faute de l'utilisateur qui clique n'importe ou)

[gloubi]

Merci pour ta réponse !

* copier / coller de l'url avec l'ID de session dedans (la faute a l'utilisateur)
* faille dans ton site qui permet par Cross Site Scripting de récuperer le cookie contenant l'ID de session (ta faute ET la faute de l'utilisateur qui clique n'importe ou)

J'ai deja pris contact avec l'utilisateur qui s'est fait hacké, et il m'assure n'avoir cliqué sur aucun lien suspect. Si je ne m'abuse, la 2e methode dont tu parles est bien celle consistant à utiliser une faille genre dans le BBCode pour placer un javascript qui va renvoyer le cookies a une adresse données !?

Concernant le timeout, le hack à eu lieu a 4h du matin, l'utilisateur ne s'étant donc pas connecté depuis plusieurs heures ! or, mon timeout est a 24 minutes... Je ne pense donc pas que le réduire d'avantage va régler le problème

EDIT : question droit également... J'ai demandé au hacker de bien vouloir m'indiqué la faille qu'il a exploiter pour réussir ceci... Il a simplement ignoré mon mail, j'en déduit donc que ce n'est pas un hacker (qui respecte une certaine éthique) mais un cracker (qui est la pour exploiter des données et rien d'autre, ce qu'il a fait)... Je compte donc déposer une plainte contre l'interessé, et je souhaiterais savoir quelles sont les chances que cela aboutisse sachant que le gars est un francais, que j'ai son IP, je sais qu'il est chez wanadoo et que le site qu'il a hacké est un site "perso", ou du moins sans but lucratif (Mon but n'est pas de faire du fric, mais juste lui faire passer l'envie de recommencer).

[Fladnag]

peut etre ton timeout ne fonctionne t'il tout simplement pas ;o)
=> a tester donc !

Autre solution : est-ce sur qu'il s'agit d'un piratage de session ? pas un simple vol de mot de passe / attaque par force brute ?

Pour la solution juridique : oui, si tu as l'IP tu peux attaquer, mais si il n'y a aucun préjudice chiffrable (ce qui n'est pas le cas je pense) il n'y a pas grande chance que ca aboutisse. Tu peux tout de meme envoyer l'info (que tu porte plainte) a ton hacker, a moins qu'il te dise comment il a fait, n'hesite pas a insister, en général ils aiment se vanter de leurs exploits ces gens là, meme les plus méchants ;o)

[gloubi]

Pas de certitude pour le vol de mot de passe brute. JE me suis aussi renseigné aupres qu hacké pour être sur de ce qu'il a fait ou pas fait de son mot de passe :

j'ai jamais refilé mes mails et mes mots de passe à quiconque (sachant que mes mots de passe comportent à la fois des lettres, des chiffres et des caractères spéciaux)

Sachant que les mdp sont bien cryptés en MD5, que j'impose une taille mini de 6 caracteres pour les mdp, je pense pouvoir exclure cette hypothèse.

Concernant le timeout, j'ai peut être mal compris... Moi, je parle du timeout du php.ini. Apres le hack, j'ai bien entendu vérifier mes parametres dans le ini, et ce dernier etait a 1440 secondes.

Le stockage des sessions se fait en fichier, le répertoire de stockage /tmp (donc 777) ce qui constiturai bien une faille de sécurité si ce n'était pas un serveur dédié (donc là, 1 seul utilisateur, moi). Par acquis de conscience, je vais changer le repertoire et limiter les droits, mais bon...

Parlais tu bien du même timeout ou pensais-tu a un timeout fait maison ?

Sinon, pour le juridique, ce genre d'action est passible d'emprisonnement (3 ans je crois)... A defaut de subir un réel préjudice financier qui ne peut donc donner lieu a des dommages et interets, je préfèrerait faire miroiter l'option emprisonnement en punition pour l'esprit "malveillant" de ses actes...
Ensuite, j'avous que ça me fait chier de lancer une action en justice pour si peu, mais si autant j'ai un profond respect pour les hacker, c'est très différent pour les cracker !

[Fladnag]

bon, deja :

* le timeout il faut que tu le teste, ce n'est pas parce que c'est parametrable que c'est implémenté correctement par la version de php, et j'ai deja vu des sessions durer plus longtemps que prévues a cause d'autres mauvais parametrages
* 6 caracteres n'est PAS suffisant. 6 caracteres peut etre cassé en force brute facilement. On estime aujourd'hui qu'un mot de passe doit faire un minimum de 8 caracteres pour que le cassage par force brute prenne trop de temps (meme si ca reste possible, ca doit etre de l'ordre de 3 mois a plein temps avec un gros ordi maintenant (je donne ce chiffre de 3 mois au hasard, mais il me parait cohérent))

[gloubi]

Je vais demander au gars la taille de son mot de passe...

sinon, as tu jetter un coup d'oeil à ce post post ? Pour ma part, j'ai pas tout compris, et il m'a rendu un peu parano...

pour le PHP, oui, le timer du php.ini fonctionne. En revanche, je crois qu'il s'agit en réalité d'une inactivation de la session : le fichier cookies reste présent dans /tmp jusqu'a ce que le script cron fasse son boulot...

Enfin, je serais toujours désireux de savoir ce que signifient les termes Cross Site Scripting...

Si je ne m'abuse, la 2e methode dont tu parles est bien celle consistant à utiliser une faille genre dans le BBCode pour placer un javascript qui va renvoyer le cookies a une adresse données !?

C'est ce que je pensait ou je suis a coté de la plaque ?!

EDIT : je réfléchissait au terme mais... Cross, si je ne m'abuse, ça veut dire traverser... donc ça serait un piratage en faisant traverser un site qui récupère l'ID de session des utilisateurs de mon site ?? Si c'est le cas, comment peut-on récupérer un ID de session sur un autre site, et surtout comment s'en protéger !?

Pour info, n'étant pas 100% novice en hack, toutes les pages se transmettent les une aux autre des variables de nom aléatoire et de contenu aléatoire et crypté qui sont vérifiés en session à chaque chargement. On évite ainsi a quelqun de lui faire cliquer la ou il veut pas en traversant d'autre site...

[Xunil]

Je vais peut-être dire une connerie, mais il me semble que la seule façon de pouvoir accéder aux ids de session est que celui qui te pirate possède un site sur le même hébergement que toi, la faute en reviendrait à ton hébergeur qui a laissé une directive dans le php.ini activée/ou désactivée(je sais plus son nom )

Il me semble que pour parer ce problème, un session_regenerate_id doit être utilisé.

Mais le moyen le plus sûr quand on est sur mutualisé est de coder soi même son script de session via une bdd.

Si t'as un dédié, alors là je sais pas

[vg33]

Ce n'est pas très difficile de voler un id de session.
Le pirate fait cliquer sur un lien qui contient en GET l'id de session. Quand php reçoit l'id de session, il constate qu'il n'existe pas (forcément, le pirate vient de l'inventer), et il ouvre une session avec cet id... Et c'est là la faille. En effet, le pirate n'a plus qu'à utiliser cet id qu'il a injecté et il navigue comme l'utilisateur authentifié...
Une parade simple est de faire un session_regenerate_id() au moins juste après la connexion.

[gloubi]

En effet, par contre, si j'ai bien suivi, cela implique que l'utilisateur se log a nouveau apres avoir visité la page pirate, puisque de toute façon, l'ancienne session de l'utilisateur est perdue...

C'est donc déjà une bonne chose à savoir

Par contre, je ne pense pas que ça soit la méthode qui ai été utilisé (qui implique quand même que l'utilisateur visite un site suspect et se relog)...
Pour essayer de trouver la faille et surtout pout ma culture personnelle, qu'existe t-il encore comme méthode pour hacker une session ?

En vous remerciant !

[Fladnag]

Si je ne m'abuse, la 2e methode dont tu parles est bien celle consistant à utiliser une faille genre dans le BBCode pour placer un javascript qui va renvoyer le cookies a une adresse données !?

c'est a peu pres ca oui, mais ca n'a pas forcement avoir avec le BBCode.

Pour le timeout et les sessions, ca fonctionne comme ca :

* Creation d'une session sur le serveur (dans /tmp) : il s'agit d'un fichier contenant les variables avec un nom qui est... l'ID de session lui meme (en général)
* Creation sur le poste de l'utilisateur d'un "cookie" qui contient juste l'ID de session et une date de timeout.

Lorsque l'utilisateur visite ton site, il envoie le cookie a ta page php qui le lit, récupere l'ID de session, et accede aux variables du fichier.

Le timeout intervient uniquement... coté navigateur du client !
Lorsque le navigateur cherche a charger le cookie, il va regarder le timeout. Si le timeout est dépassé, il supprime le cookie, sinon il l'envoie.

Cela veux dire que tant que l'utilisateur ne retourne pas sur ton site, le cookie RESTE sur le poste client indéfiniement meme s'il a un timeout (a moins que le navigateur s'amuse a effacer periodiquement les cookies expirés, mais c'est rare)

La seule exception a cette regle sont les cookies dit "de session" justement, qui sont créés avec une date de timeout spéciale qui indique au navigateur qu'ils doivent etre supprimés automatiquement lorsque l'on ferme le navigateur. Dans ce cas là le cookie est bien supprimé lorsque l'on ferme *completement* le navigateur (c'est a dire tout les onglets ou toutes les fenetres ouvertes)