[Cookies] Mon site - FAILLE sécuritaire GRAVE [Résolu]

[Just]

Bonjour à toutes et à tous,

J'espère que vous allez bien.

Le contexte:
Un site communautaire [http://www.ain-irc.net/] où les membres s'identifient via un formulaire avec login/Password.
Les infos sont stockées en session et en cookie [login et pass crypté MD5 ainsi que l'ID utilisateur unique - clé primaire de la table "user"].
Le site est référencé sous Google depuis longtemps.

La problématique:
Faites une recherche google sur l'entité "ain irc" et cliquez sur le premier lien qui pointe sur mon site. Vous remarquerez le paramêtre "ain_irc" passé en GET. C'est un identifiant de session (SID). Et là où la choses est dramatique, c'est que ça ouvre effectivement une session utilisateur et permet l'accès à un compte apparament plus ou moins aux hasards [le dernier membre logué, en règles générales]. Bien entendu j'ai temporairement bloqué ce soucis par une finte que je ne dévoilerais pas ici pour ne pas compromettre plus la sécurité des contenus de mon site [imaginons que c'est moi le dernier logé: la personne arrive sur le site en tant qu'admin O_o].
Voici le lien donné par google si jamais vous n'arrivez pas à tomber dessus: http://ain-irc.net/page/accueil.php?...7425ceb7a76095.

Mes questions:
Je ne comprend absolument pas comment est-ce possible o_O. Ni que Google enregistre une page avec un ID de session. Ni que ce dernier soit un pass-droit pour se logé sur n'importe quel compte...?! HELP SVP.

Merci d'avance pour vos précieux éléments de réponses.

[Just]

A noter que le SID n'est passé que si l'accès au site se fait via "ain-irc.net" et non via "www.ain-irc.net".

[vg33]

1) Tu ne dois RIEN stocker en cookie, en tout cas aucune donnée d'identification. Les cookies n'apportent aucune sécurité.
2) Le login doit être stocké en session ou en bdd, en tout cas côté serveur.
3) SURTOUT PAS de mdp, même en md5(), dans un cookie.

Comment faire ? Une solution.
1) Identification. => ouverture de session.
2) Si identification OK => stockage login [+ statut (...)] + timestamp actuel en session (rappel : oublie les cookies).
3) A chaque affichage d'une page protégée : vérifie que isset($_SESSION['login']), et que le timestamp n'est pas trop ancien (5 min par exemple).
4) Si OK => enregistre le nouveau timestamp.
5) Si NON ou si déconnexion => suppression de la session + renvoi à la page d'identification avec le message qui le fait bien.

Résultat : le cookie ne contient que l'id de session, et rien de plus.
Lis les tutoriels sur la sécurité pour aller plus loin (vos de cookie de session, cookie imposé par le pirate, régénération de l'id de session...).

[Just]

Tout d'abord merci à vg33 pour sa réponse rapide.

J'ai bien pris note des différentes remarques. J'avais déjà connaissance de ces éléments mais j'n'ai pour le moment pas encore eu le temps de me pencher sur ces corrections , aussi importantes soient-elles.
Elles interviendront sans nul doute dans la v3 du site, mais la date de sortie n'est pas encore fixée, donc :/.

Toujours sur ces remarques: mon site est grand public. La plus part des gens n'aiment pas avoir à se réidentifier à chacune de leur connexion... comment mémoriser leur login sans passer par la méthode actuelle? On m'a conseiller de créer une entité propre avec un ID unique qui ferait ensuite référence a l'ID user, et c'est cette ID de cette entité unique qu'on mémorise en cookie [grosso modo ca fait une session stopcké en BDD qui n'expire "jamais"]... mais bon je ne sais trop si c'est fiable ou pas :s.

Toujours est-il que les points soulevés n'éclairent pas la situation. C'est pourquoi j'aimerais préciser mes questions:
* En mon sens une session PHP a une "durée de vie" limitée... 15 minutes sur mes serveurs. Comment se fait-il que l'ID de session mémorisé par Google, qui dois dater de bien plus de 15 minutes est encore valable?
* Je nomme ma session en début de script, ensuite dans ce "groupe de session" [réunis autour du nom donné], on ouvre X sessions, une par "utilisateur" [navigateur+IP]... comment est-il possible que le SID mémorisé par Google puisse correspondre avec une des sessions ouvertes il y a perpette O_o?

[gloubi]

3) SURTOUT PAS de mdp, même en md5(), dans un cookie.

Sans ça, comment peux-tu faire un site ou tu n'as pas besoin de te logger à chaque visite sans compromètre gravement la sécurité !?

Pour information, je lisais dans je sais plus quel magazine scientifique un article sur le MD5, ou un mathématicien annonçait fièrement avoir réussi à dessendre la probabilité de trouver une chaine ayant comme md5 un mot désiré a 1 sur 2 puissance 51 (et c'est le record actuel)... Essayez de le taper sur la calculatrice voir ce que ca représente...

Dans ces conditions, si votre site est bien codé (pas de moyen de rentrer direct le md5 du mdp au login), je ne vois pas ce que l'on risque à stocké un MD5...

[vg33]

Envoyé par gloubi

Dans ces conditions, si votre site est bien codé (pas de moyen de rentrer direct le md5 du mdp au login), je ne vois pas ce que l'on risque à stocké un MD5...

Il y a deux solutions (hors https) pour transmettre un mdp du formulaire/cookie vers le serveur :
1) transmission en clair => risque de sniffing (le pirate récupère le mdp en clair et l'utilise comme il veut)
2) transmission hasché en md5 par js (le plus courant).

Si tu utilises la solution 2), le script n'a aucun moyen de savoir si tu as envoyé le mdp en clair hasché par javascript, ou si tu as envoyé directement le hasch en désactivant js. Donc le pirate récupère le md5 de ton mdp, l'envoie par ton formulaire, et est connecté à ta place.
De plus, si tu utilises la solution 1), il ne faut pas oublier que la quasi totalité des internautes utilise le même mot de passe pour toutes les applications... et que certaines utilisent la solution 2)... Bref, le problème est le même : le pirate se connecte à ta place.

Alors, comment faire une connexion automatique. Pas en stockant login et mdp en cookie => JAMAIS DE DONNÉE CONFIDENTIELLE EN COOKIE.
Une solution : générer à la création du compte un id unique spécifique à l'application, qui lui sera stocké en cookie. Ainsi, si le pirate récupère cet id, il peut se connecter à l'application (comme avec le login et le mdp), mais à aucune autre (puisque l'id n'a aucun lien avec le login et le mdp). A la nouvelle connexion, tu récupères l'id, et tu stockes en session (donc beaucoup plus sécurisé) les données confidentielles (login, rôle, panier...).
De toute façon, à ma connaissance, tu ne peux pas sécuriser une connexion automatique. Mais tu peux empêcher de pirater le site des copains

[gloubi]

J'ai beau y réfléchir, je trouves cette solution mauvaise...
Quel est le risque de se faire sniffer comparer au risque que :
- quelqun récupère votre cookies
- quelqun génère un numéro d'ID au hasard
Pour le premier cas, il est immensément plus probable que quelqun arrive a récupéré votre cookies (ex : faille de sécurité sur une balise BBCode) plutot que de vous sniffer...
Pour le 2e cas, c'est pas vraiment l'utilisateur qui est mis en danger, mais la sécurité de votre site, car si la proba de se faire hacké individuellement est faible, celle que le site laisse se connecter des utilisateurs non légitimes est énorme (bien que je te l'accorde, ça dépende de la façon dont tu code ça et du nombre d'utilisateurs)... D'autant que l'utilisateur n'est pas a l'abris du vol de cookies non plus...
Moué... en fait, a l'avenir, je pense que j'opterai pour un compromis du genre MD5($login_user.$pass_user.$clef) en tant qu'ID

[Just]

Salut,

Merci pour vos réponses!
Je reviens ici un peu "en retard" ^^.

Effectivement la solution de l'ID unique est très intéressante.
Je pense exploité cette piste dans mes futurs développement.

Merci à tous pour vos contributions!