par
devlop78 » 19 janv. 2011, 21:47
Hum et si la personne a quitté le site sans se déconnecter ?
La session est de nouveau active à l'ouverture du site(via le mail).
C'est surtout ce genre de faille qui pose problème.
Car le fait de générer des valeurs aléatoire pour chaque session ne pose pas gros problème.
Oui, mais que peut-il faire sans token ...
Bah si le token est en corrélation avec la session il l'a le token ?_?
Le coup du referer j'aime pas trop car c'est modifiable...
Par contre le timestamp pour l'inactivité j'aime bien ! Je vais rajouter cela à mon système de session.
Non, ou alors on parle du XSS ... Pour le CSRF, le "méchant" n'a même pas conscience du n° de session, il utilise juste le fait que le gentil soit connecté. Le problème, c'est que le gentil va sur delete.php qui génère (on va prendre le cas du GET), des liens de type delete.php?id=5 mais avec un token donc delete.php?id=5&token=C589DE44DDEE44, token qui va changer à chaque page, ou qui dure toute la session (ici dans mon exemple ça ne change rien). Si le méchant envoie un email au gentil avec une image src="gentil.com/admin/delete.php?id=5", il ne passera rien puisque le token, il ne l'a pas. Pour l'avoir, il faudrait qu'il utilise des techniques telles qu'il aura de fortes chances d'avoir aussi le numéro de session avec ... donc de toutes façons ... Par contre en limitant le temps d'inactivité, et en enregistrant le nom du navigateur, des infos par ci par là (qu'on dit alors devenir unique, comme la prise en charge de Flash etc), le site peut comparer ça à chaque fois, et deconnecter d'urgence si il y a la moindre incompatibilité. Or, un navigateur ne change pas de nom lors d'une même session, et ne change pas trop de configuration non plus. Et au pire, il s'agit de la sécurité, devoir se reconnecter, c'est pas grand chose. C'est d'ailleurs tout aussi primordial pour les grandes opérations.
[quote="xTG"][quote="devlop78"][quote="xTG"]Hum et si la personne a quitté le site sans se déconnecter ?
La session est de nouveau active à l'ouverture du site(via le mail).
C'est surtout ce genre de faille qui pose problème.
Car le fait de générer des valeurs aléatoire pour chaque session ne pose pas gros problème.[/quote]
Oui, mais que peut-il faire sans token ...[/quote]
Bah si le token est en corrélation avec la session il l'a le token ?_?
Le coup du referer j'aime pas trop car c'est modifiable...
Par contre le timestamp pour l'inactivité j'aime bien ! Je vais rajouter cela à mon système de session.[/quote]
Non, ou alors on parle du XSS ... Pour le CSRF, le "méchant" n'a même pas conscience du n° de session, il utilise juste le fait que le gentil soit connecté. Le problème, c'est que le gentil va sur delete.php qui génère (on va prendre le cas du GET), des liens de type delete.php?id=5 mais avec un token donc delete.php?id=5&token=C589DE44DDEE44, token qui va changer à chaque page, ou qui dure toute la session (ici dans mon exemple ça ne change rien). Si le méchant envoie un email au gentil avec une image src="gentil.com/admin/delete.php?id=5", il ne passera rien puisque le token, il ne l'a pas. Pour l'avoir, il faudrait qu'il utilise des techniques telles qu'il aura de fortes chances d'avoir aussi le numéro de session avec ... donc de toutes façons ... Par contre en limitant le temps d'inactivité, et en enregistrant le nom du navigateur, des infos par ci par là (qu'on dit alors devenir unique, comme la prise en charge de Flash etc), le site peut comparer ça à chaque fois, et deconnecter d'urgence si il y a la moindre incompatibilité. Or, un navigateur ne change pas de nom lors d'une même session, et ne change pas trop de configuration non plus. Et au pire, il s'agit de la sécurité, devoir se reconnecter, c'est pas grand chose. C'est d'ailleurs tout aussi primordial pour les grandes opérations.
