Discussion :

[Doonge]

Bonjour,


je m'intéresse épisodiquement à la programmation depuis quelques années, ce qui m'a servi à écrire divers petits utilitaires à but personnel.

Je me suis intéressé il y a assez longtemps aux sessions (lorsqu'elles ont été incorporées à PHP), et j'ai donc créé une petite classe perso (probablement pas géniale mais bon) de sessions (sans utiliser les fonctions session de PhP).

J'utilisais donc un identifiant de session, qu'il fallait propager via les cookies, et je conservais les données dans une table SQL dédiée aux sessions, avec un certain nombre de précautions visant à avoir une bonne sécurité.



Il se fait que je reprend maintenant mes vieux bouts de code, et je lis la littérature sur le sujet, et je découvre avec intérêt un système de session qui dépendrait désormais essentiellement des cookies, et qui ne nécessiterait plus du tout de table SQL dédiée aux sessions.

Si quelqu'un est curieux je peux développer un peu le sujet, mais mes problèmes sont les suivants :



Le gros soucis théorique qui me bloque dans l'implémentation de cette méthode, c'est que je perd une protection que j'aimais bien contre l'hijacking de session.


En résumé, si un pirate arrive à sniffer le cookie et copier son contenu, il possède une session valide.

Auparavant, je gérais ce cas en stockant le nombre de visites effectuées pendant la session, et en l'incrémentant automatiquement dans le cookie. Ce qui fait que si un internaute surfe et se fait sniffer sa session, le pirate ne peut l'utiliser que lorsque l'internaute arrête de surfer, car sinon je détecte facilement que le nombre de visites ne correspond pas (je reçois deux fois un cookie qui déclare que l'internaute X a déjà fait 10 visites, info que je stocke aussi dans la BDD).

Et je ne vois absolument pas comment détecter deux sessions qui se chevauchent sans utiliser une technique qui implique SQL (ce qui tue l'un des avantages des sessions qui se basent uniquement sur les cookies).

Enfin bref, la meilleure technique que je trouve actuellement, c'est d'enregistrer les log (ce que je fais de toute façon) dans une table SQL, qui est analysée et nettoyée tous les mois (ou plus fréquemment si ya du passage), et d'inclure dans les logs le couple (user_id . timestamp de la session), et d'imposer qu'il soit unique.
Donc si un internaute essaye d'utiliser un cookie qui a déjà été utilisé, je ne vais pas pouvoir l'inclure dans les logs (erreur SQL j'imagine), et je saurai qu'il y a éventuellement tentative d'hijacking.


=> Une erreur SQL sur une insertion dans une table pour cause de non-unicité d'un des champs est une solution élégante ou non puisqu'elle dépend d'une erreur ?

=> Un internaute qui "clique trop vite" ne va-t-il pas générer cette erreur ?
Si je permet deux clicks dans un intervalle très court (pour gérer ce comportement), c'est laisser une fenêtre ouverte à un hijackeur qui sait "cliquer" en même temps plus ou moins que sa victime (et je sais pas si c'est possible, ou si je suis parano ^^).






Une autre méthode que j'utilisais aussi, c'est enregistrer l'user-agent de l'internaute, car il n'est pas censé changer. Mais quelqu'un capable de sniffer un cookie est à mon avis complètement capable de copier l'user-agent ...
Donc utiliser l'user-agent comme élément de sécurité n'a d'intérêt que contre les voleurs de cookies qui ne savent pas se procurer l'user-agent de leur victime (ça existe?).


Merci de m'éclairer, et désolé si je suis un peu brouillon dans mes explications.

[manticore]

Salut,

le hijacking est un vrai problème, mais j'ai pas l'impression que tes méthodes permettent de t'en protéger.

Incrémenter ton champs PHPSSID (id de l'utilisateur) est inutile si on peut le prédire. La seule méthode que je vois est d'utiliser des nombres et des caractères suffisament grand que tu vas passer dans une fonction de hachage. Ces nombres doivent évidement être générés aleatoirement.

Si tu d'utilises une valeurs en clair, je pense qu'il faut quelques minutes pour trouver ton incrément (si le hacker peut créer une sessions sur ton site c'est beaucoup moins long avec des outils appropriés).

Enfin bref, la meilleure technique que je trouve actuellement, c'est d'enregistrer les log (ce que je fais de toute façon) dans une table SQL, qui est analysée et nettoyée tous les mois (ou plus fréquemment si ya du passage), et d'inclure dans les logs le couple (user_id . timestamp de la session), et d'imposer qu'il soit unique.

le user + timestamp sera de toute façon unique à moins que tu mettes un delta de plusieurs secondes, ce qui doit être très peinible pour l'utilisateur (impossible de refresh).

De plus, il n'est pas difficile d'écrire un script qui calcul le temps minimum que tu imposes. Après tu peux toujours bloquer le compte en cas de tentatives de fraudes... mais la encore tu risques d'avoir des faux positifs et d'embêter tes utilisateurs.

=> Une erreur SQL sur une insertion dans une table pour cause de non-unicité d'un des champs est une solution élégante ou non puisqu'elle dépend d'une erreur ?

Je pense qu'elle ne te protège pas du tout. Niveau code par contre rien à redire.

=> Un internaute qui "clique trop vite" ne va-t-il pas générer cette erreur ?

En plus c'est peinible pour l'utilisateur. Car oui, il va générer cette erreur.

Une autre méthode que j'utilisais aussi, c'est enregistrer l'user-agent de l'internaute, car il n'est pas censé changer. Mais quelqu'un capable de sniffer un cookie est à mon avis complètement capable de copier l'user-agent ...
Donc utiliser l'user-agent comme élément de sécurité n'a d'intérêt que contre les voleurs de cookies qui ne savent pas se procurer l'user-agent de leur victime (ça existe?).

Règle numéro 1 : Ne jamais se fier aux informations envoyé par l'utilisateur. Récupérer l'user-agent est simple comme le monde, si tu es en position d'hijacking.

N'oublie cependant pas que ton site ne détient surement pas des secrets bancaires, ou rien qui ne justifie du hijacking. Qui demande quand même de se retrouver en situation ou l'on peut sniffer le réseau de sa cible (ce qui n'est pas du tout évident à distance).

Et si j'ai tord sur le dernier points et que tu détiens des informations vraiment sensible -> implémente de l'https qui te fournira une sécurité nettement plus importante.

A part de l'https, je ne vois pas de solution solide contre du hijacking...

Coordialement Manticore

[Doonge]

Merci.

Je sais qu'il est difficile de se protéger contre l'hijacking, et que dire des keyloggers ...

Je n'incrémente pas le PHPSID, mais un compteur de visites propre à la session.
Mais bon, soit j'impose que ce compteur soit unique (ce qui risque fort de gêner les utilisateurs), soit je tolère une fenêtre de validité (ce qui diminue fortement l'intérêt et alourdit le code).
De toute façon ce verrou de sécurité ne marche de toute façon pas si le hijackeur attend que l'internaute sorte de mon site.


Je réagis à

le user + timestamp sera de toute façon unique à moins que tu mettes un delta de plusieurs secondes, ce qui doit être très peinible pour l'utilisateur (impossible de refresh).

Car même si ta réponse me satisfait, j'ai l'impression de ne pas m'être fait comprendre ^^

Un système de session sur cookie est de la forme, si j'en crois de solides sources datant de 2008,

user_id (ou user_name)
+
peremption_cookie (un timestamp)
+
encryption[data , cle_encryption] (l'encryption de data est optionnelle selon les désirs de confidentialité)
+
hash_mac[user_id + peremption_cookie + data + identifiant de session, cle_encryption]

Avec la clé de l'encryption valant
cle_encryption = hash_mac[user_id + peremption_cookie, cle_encryption_serveur]

Ce qui permet, comme d'autres systèmes de sessions :
- de continuer à authentifier un utilisateur qui s'est authentifié à un moment dans la session (donc récemment, en fonction de la durée de péremption qu'on fixe)
- de contrôler le niveau de confidentialité de la session (on peut choisir de crypter ou non data dans le cookie)
- de s'assurer que le cookie ne peut être inventé ou modifié (via un système de hashage qui varie pour chaque cookie, et qui dépend d'une clé de hashage coté serveur qui n'est donc pas sensible aux attaques de volume puisque ce n'est pas cette clé qu'on utilise au final (mais un hash de cette clé avec un sel variable qui dépend du timestamp et de id_user)).


Mais il empêche difficilement hors SSL que le cookie soit copié (volé).
L'identification de session n'est PAS phpsid, mais la clé SSL dans le cas d'une connexion sécurisée (donc protégé contre l'hijacking), et il n'y a aucune spécification dans le cas d'une connexion non sécurisée (donc vulnérable à l'hijacking).

Une parade éventuelle, c'est d'imposer l'unicité de la clé user_id , timestamp.
Le problème, c'est que si un utilisateur clique deux fois "trop vite", le serveur n'aura pas le temps de donner le "nouveau" cookie avant qu'il ne soit envoyé à la 2ème requete, et donc l'utilisateur enverra lui-même deux fois le même cookie, alors qu'il n'y a pas du tout de tentative d'hijacking.

(et c'est ce que tu as confirmé je crois)




J'utilise l'user-agent comme indice d'identification dans le hash, car si je sais que ce n'est pas une donnée fiable, au moins je sais que c'est la seule information de $_SERVER venant de l'utilisateur qui n'est pas censé changer en cours de session (contrairement à l'ip par exemple). Il est important que ce soit un élément quasi invariable, et c'est mieux lorsque c'est un élément unique et difficilement volable (comme une clé SSL), mais je n'ai rien d'autre que l'user-agent.

Il est possible, facile et efficace d'utiliser un verrou qui observe la "tendance" de l'IP de l'utilisateur à ne pas changer (si elle ne change pas après 20 pages visitées, elle n'est pas censé changer ensuite), pour utiliser l'IP comme identifiant de session, mais ça ne marche que pour ceux qui ont une IP fixe, donc même je vais probablement intégrer ce système de "tendance" (une petit sécurité supplémentaire), il ne protègera pas tout le monde.

[manticore]

Ok je commence à mieux comprendre ce que tu fais

Donc juste pour être sur que l'on parle de la même chose :
1. ton compteur de visite te sert à générer un nouvel identifiant à chaque requête http.

2. tu utilises un timestamp + user_id, tu imposes l'unicité, mais avec quel moyen ?

user_id (ou user_name)
+
peremption_cookie (un timestamp)
+
encryption[data , cle_encryption] (l'encryption de data est optionnelle selon les désirs de confidentialité)
+
hash_mac[user_id + peremption_cookie + data + identifiant de session, cle_encryption]

Avec la clé de l'encryption valant
cle_encryption = hash_mac[user_id + peremption_cookie, cle_encryption_serveur]

Toujours bon à savoir, merci.

Cependant, à moins que je loupe quelques chose, ta protection, ne fais que changer plus souvent le phpssid (on va l'appeler comme ça, qui correspond à l'identifiant de session de l'utilisateur stocker dans un cookie).

Donc à quoi te sert-elle ? Penses-tu te protéger contre quel scénario d'attaque ?

Une parade éventuelle, c'est d'imposer l'unicité de la clé user_id , timestamp.
Le problème, c'est que si un utilisateur clique deux fois "trop vite", le serveur n'aura pas le temps de donner le "nouveau" cookie avant qu'il ne soit envoyé à la 2ème requete, et donc l'utilisateur enverra lui-même deux fois le même cookie, alors qu'il n'y a pas du tout de tentative d'hijacking.

(et c'est ce que tu as confirmé je crois)

Comme je te le dis au début du texte, comment imposes-tu cette unicité ?

Il est possible, facile et efficace d'utiliser un verrou qui observe la "tendance" de l'IP de l'utilisateur à ne pas changer (si elle ne change pas après 20 pages visitées, elle n'est pas censé changer ensuite), pour utiliser l'IP comme identifiant de session, mais ça ne marche que pour ceux qui ont une IP fixe, donc même je vais probablement intégrer ce système de "tendance" (une petit sécurité supplémentaire), il ne protègera pas tout le monde.

Effectivement cela fonctionne, mais le problème c'est que pour faire de l'hijacking il faut en principe sniffer le réseau, donc on est souvent dans le même réseau que la cible. Comme la plupart des réseaux utilisent des translations NAT on se retrouve avec la même adresse IP que la cible donc ta protection saute.


Encore un dernier point que se passe-t-il pour ton user si, son browser plante alors qu'il devait recevoir le dernier cookie ? Combien de temps sera t-il banni si il n'a pas reçu le bon cookie ? Suffit-il pour lui de se reconnecter ?

[Doonge]

1. Le compteur de visite servait à assurer la continuité et l'unicité d'une session. Mais il est entaché du problème des doubles click. Il ne sert pas spécifiquement à générer un nouvel identifiant à chaque requête HTTP (je n'en vois pas l'intérêt), mais agit comme une protection contre deux utilisateurs utilisant en même temps la même session (c'est la réponse à ta question sur pourquoi imposer l'unicité : un cookie ne PEUT PAS avoir été utilisé deux fois, donc un cookie volé et utilisé par le voleur et la victime avertit d'un problème). C'est peut-être assez similaire au fait de générer un nouvel identifiant de session (session_regenerate_id ?) en pratique (les objectifs). Mais ça me semble moins lourd pour le même effet (générer des nouvelles sessions à chaque page c'est lourd).

2. L'unicité ne s'impose que s'il y a moyen de comparer, donc d'avoir stocké qq part ces valeurs. Si je stocke cela dans ma base SQL, je réduis une partie de l'intérêt des session basées sur les cookies. Bref, si une requête INSERT (user_id+timestamp , infos...) dans une table sql_logs échoue parce que j'impose l'unicité du champs user_id+timestamp, je peux récupérer l'erreur et reset la session (je ne ban pas).

Cependant, à moins que je loupe quelques chose, ta protection, ne fais que changer plus souvent le phpssid (on va l'appeler comme ça, qui correspond à l'identifiant de session de l'utilisateur stocker dans un cookie).

Basiquement, et je vais peut-être répondre à d'autres questions que tu as posées à la suite, c'est un système qui anéantit un peu le système de sessions. Au lieu d'être un système de session avec un "identifiant", c'est un système qui "donne" à l'utilisateur un certain nombre d'infos sur sa session de façon "cryptée (il y a un hash de vérification de l'intégrité des données du cookie), et c'est ce hash qui garantit si les données du cookie sont valables ou non. Ce n'est pas l'existence ou non d'un phpsessid dans une table SQL qui répertorie les sessions actives.
Le garant de la session, ce n'est pas l'identifiant, mais le hash de vérification qui garantit que le cookie a bel et bien encrypté par nous même.

Effectivement cela fonctionne, mais le problème c'est que pour faire de l'hijacking il faut en principe sniffer le réseau, donc on est souvent dans le même réseau que la cible. Comme la plupart des réseaux utilisent des translations NAT on se retrouve avec la même adresse IP que la cible donc ta protection saute.

Si ce que tu dis est vrai, je peux supposer que le système n'est tout simplement pas sécurisable contre le vol de cookie tant que je n'utilise pas de système comme le SSL. Cela me va.

J'ai une question peut-être pointue :
J'ai prévu ce cas (il me semblait probable), et je me suis dit que le cookie suffirait pour la plupart des actions pas spécialement "graves" de mon site, et que j'imposerais la réidentification (avec un formulaire) pour les actions à sécuriser.
Mais j'ai l'impression que voler un cookie et intercepter des données $_POST, c'est un peu la même chose ... (tout est dans l'en-tête de la requête ?).

Encore un dernier point que se passe-t-il pour ton user si, son browser plante alors qu'il devait recevoir le dernier cookie ? Combien de temps sera t-il banni si il n'a pas reçu le bon cookie ? Suffit-il pour lui de se reconnecter ?

Je ne ban pas, je nettoie la session, donc il faut se reconnecter, oui (si j'impose le système d'unicité, ce dont je suis de moins en moins sûr).
Si je n'utilise pas le système d'unicité, et que j'assume que la session n'est pas protégée contre l'hijacking (si je veux une session plus sûre je dois utiliser SSL ou autre), le plantage du browser ne sera pas grave pour la session : le cookie sera toujours valide (sauf s'il devient périmé).

Je te fais remarquer que les échanges de cookie se font au tout début (avant la réception du code HTML), donc c'est quand même rare ce cas.

[manticore]

1. Le compteur de visite servait à assurer la continuité et l'unicité d'une session. Mais il est entaché du problème des doubles click. Il ne sert pas spécifiquement à générer un nouvel identifiant à chaque requête HTTP (je n'en vois pas l'intérêt), mais agit comme une protection contre deux utilisateurs utilisant en même temps la même session (c'est la réponse à ta question sur pourquoi imposer l'unicité : un cookie ne PEUT PAS avoir été utilisé deux fois, donc un cookie volé et utilisé par le voleur et la victime avertit d'un problème). C'est peut-être assez similaire au fait de générer un nouvel identifiant de session (session_regenerate_id ?) en pratique (les objectifs). Mais ça me semble moins lourd pour le même effet (générer des nouvelles sessions à chaque page c'est lourd).

Donc ton cookie ne peut-être utilisé qu'une seule fois ok. Une fois utilisé je suppose que l'utilisateur en reçoit un nouveau ? C'est juste ?

sa session de façon "cryptée (il y a un hash de vérification de l'intégrité des données du cookie)

Attention à ne pas confondre crypter et hacher c'est pas du tout la même chose.

J'ai une question peut-être pointue :
J'ai prévu ce cas (il me semblait probable), et je me suis dit que le cookie suffirait pour la plupart des actions pas spécialement "graves" de mon site, et que j'imposerais la réidentification (avec un formulaire) pour les actions à sécuriser.
Mais j'ai l'impression que voler un cookie et intercepter des données $_POST, c'est un peu la même chose ... (tout est dans l'en-tête de la requête ?).

Absoluement les cookies sont insérées dans l'en-tête alors que les post sont dans le "corps", tout est en principe accessible avec les mêmes outils, je te conseils d'essayer quelques add-ons de firefox pour voir comme cela se présente par exemple : tamperdata, qui te permet d'intercepter les requêtes http

Je te fais remarquer que les échanges de cookie se font au tout début (avant la réception du code HTML), donc c'est quand même rare ce cas.

Ton cookie est envoyé avec chaque requête http, et oui c'est rare mais je pensais que tu faisais un ban.

Si ce que tu dis est vrai, je peux supposer que le système n'est tout simplement pas sécurisable contre le vol de cookie tant que je n'utilise pas de système comme le SSL. Cela me va.

En tout cas à ma connaissance, il n'existe pas de système de sessions fiable n'utilisant pas de cryptographie.

[Doonge]

Oui l'utilisateur reçoit un nouveau (nouvelle date de péremption au minimum, cela m'a l'air classique et inhérent à beaucoup de système de session que j'ai vues, donc nouvelle clé de hash etc... mais ce n'est vraiment pas gourmand).

Par contre ce qui m'ennuie c'est que si le cookie est envoyé à chaque requete, il est envoyé à chaque téléchargement d'image ou de fichier css (tout ce qui pointe vers des ressources dans dans le code html), et donc un cookie trop lourd ralentit à mon avis fortement la communication entre le site et l'utilisateur (de plusieurs dizaines voire centaines de ms).

Je vais devoir réfléchir à ce que je met dedans avec beaucoup de parcimonie.



Oui crypter et hasher ce n'est pas la même chose ^^


Si finalement s'authentifier via un formulaire (sans SSL) n'est pas particulièrement plus sécurisé que via un cookie, qu'est ce qui me retiendrait de donner une longue durée de vie à mes cookies ?

edit : les imbéciles qui ne se delog pas dans les cybercafés probablement.
edit2 : il n'y a pas de fonction d'encryption/décryption dans le core php?

[manticore]

Par contre ce qui m'ennuie c'est que si le cookie est envoyé à chaque requete, il est envoyé à chaque téléchargement d'image ou de fichier css (tout ce qui pointe vers des ressources dans dans le code html), et donc un cookie trop lourd ralentit à mon avis fortement la communication entre le site et l'utilisateur (de plusieurs dizaines voire centaines de ms).

Ton poste m'intéresse beaucoup, cependant, je pense que la meilleur solution pour toi est de mettre en place un service ssl si tu as vraiment besoin de sécurité et sinon d'utiliser les méthodes classiques de php pour la gestion des sessions.

Il ne faut pas oublier un principe d'un système de sécurité qui doit être audité pour le tester, ton système perso à des chances de créer de nouvelles failles.

Si finalement s'authentifier via un formulaire (sans SSL) n'est pas particulièrement plus sécurisé que via un cookie, qu'est ce qui me retiendrait de donner une longue durée de vie à mes cookies ?

Attention à ne pas mélanger. Ton cookie est souvent créer après l'authentification de l'utilisateur. Ton formulaire va te servir à attribuer ta session à un utilisateur spécifique qui a des préférences et des données personnelles.

Sinon pour la durée, c'est comme tu le dis pour les gens au cyber, mais aussi pour les gens utilisant un p.c. commun à plusieurs personnes.

Pour les fonctions d'encryption/decryption de php, je ne suis pas compétent pour te répondre

En résumé, je te conseille d'utiliser les fonctions php pour les sessions, avec si besoin est une session SSL pour créer la session lors du login (phase sensible ou il est possible de sniffer le login-mdp). Et de la maintenir si tu en as besoin pour le reste du travail.

Bien que le hijacking existe, il faut rester réaliste, les chances que quelqu'un hijack tes clients est mince, et si il est compétent, tes chances de le bloquer sont quasi nul.

[Doonge]

Il me semble que ce n'est pas "ma technique perso" ^^
je crois que c'est déjà utilisé dans beaucoup de gros sites (où le nombre de connectés est grand, ce qui emmerde pas mal une table sql_sessions et ralentit à fond un site).
Il faudrait analyser les cookies que tu as, pour voir si certains venant de gros sites connus présentent des cookies qui ne semble pas se contenter d'un truc comme "cookie_phpsessid".


Je vais probablement utiliser une fonction de php, celle qui définit les fonctions de session ... ^^
session_save_set_handler je crois.
Car je n'aime pas beaucoup l'implémentation classique de php sur les sessions (donc je préfère la faire moi-même).


Je ne compte pas utiliser SSL tout de suite, mais je soupçonne qu'il faut prendre certaines précautions s'il faut fournir à l'utilisateur des sessions hybrides (passages SSL et passages sans SSL). Notamment à mon avis un reset d'id de session parce que ce ne sont pas des choses qu'on mélange réellement (juste ça doit être transparent pour l'utilisateur).


Je n'ai pas de client, je fais ça juste pour le plaisir ^^
Mais j'aime bien maîtriser mes sujets, et je tombe souvent sur des sites de débutants pour débutants où on ne donne que très peu de détails techniques.
La documentation (accessible sur internet) sur la sécurité est des plus disparates.


Si je résume le fil :

- Surveiller l'unicité d'utilisation des "tokens" (peu importe comment ils sont construits) de session est une technique lourde, pas efficace à 100% (reprise de la session lorsque l'internaute change de site en cas de surveillance de son traffic, par exemple), et potentiellement gênante pour l'utilisateur (double-clic).

- $_POST n'est pas plus fiable qu'un cookie, donc ça ne sert à rien de redemander les accès d'un utilisateur pour les données sensibles, il faut passer par SSL, principalement à cause du hijacking.

- Donc utiliser les cookies au lieu d'une table SQL est une excellente alternative (que ce soit SSL ou non, ça ne change pas les problèmes de sécurité à priori - le cookie est très bien protégé en SSL pare qu'il contient le hash de la clé SSL connue uniquement de l'utilisateur et du serveur), à condition de faire attention à ce qu'on place dedans : trop d'information ralentit la communication.

- je ne sais pas comment se protéger contre les attaquants qui désactivent les cookies (flood).

[manticore]

- Surveiller l'unicité d'utilisation des "tokens" (peu importe comment ils sont construits) de session est une technique lourde, pas efficace à 100% (reprise de la session lorsque l'internaute change de site en cas de surveillance de son traffic, par exemple), et potentiellement gênante pour l'utilisateur (double-clic).

Oula attention, ton internaute n'est pas sur un site ! Ton internaute demande une page la reçoit et c'est tout. Je comprends maintenant ce que tu entends pas unicité, . Mais non tu peux pas le faire car ton internaute te renvoie à chaque requête son cookie pour te dire : "hello c'est toujours moi". Voici mon identité...

A mon avis il serait bien que tu regardes plus en détails le protocole http, il te manque certains fondamentaux.

je ne sais pas comment se protéger contre les attaquants qui désactivent les cookies (flood).

Tu demandes le cookie, si il n'y en as pas, tu laisses tomber la requête De nos jours tout le monde accepte les cookies

[Doonge]

Je dois laisser certains bots archiver et référencer mes pages.

Il est impossible de vérifier si un utilisateur accepte ou non un cookie : un script malicieux peut accepter le cookie, et l'effacer directement : je ne le remarquerai pas à la prochaine requete.

Quand je n'ai pas de cookie, j'initialise une nouvelle session (j'envoie un cookie visiteur).
Une attaque efficace avec un système SQL de session, et beaucoup moins efficace avec un système cookie de session, c'est flooder de requete en supprimant ses cookies : le site va créer énormément de sessions.



Je ne pense pas que tu comprennes ce que je veux dire pas unicité si tu réagis à ma phrase sur le site.
Je voulais dire qu'un pirate peut voler le cookie d'une victime, puis surveiller l'activité de sa victime et utiliser son cookie quand sa victime aura décidé d'arrêter de visiter mon site durant un petit moment si j'installe un système d'unicité.
Je m'exprime peut-être mal, mais le concept m'a l'air simple à comprendre : chaque cookie que j'envoie, chaque "token d'identification" si je reprend ton langage même si ce n'est pas ça dans mon système, n'est idéalement utilisé qu'une seule fois par un utilisateur lambda (sauf lorsqu'il double click).
Si je parviens à détecter qu'un cookie a été utilisé deux fois, c'est soit parce que l'utilisateur a cliqué deux fois (ou plus), soit parce qu'il s'est fait hijack alors qu'il continue de visiter mon site.
S'il arrête de visiter mon site, le dernier cookie que j'ai envoyé peut parfaitement être employé par le pirate.
L'unicité d'utilisation d'un cookie n'empêche pas un pirate de "continuer" une session volée (au lieu de surfer "en parallèle" => busted).

Ce qui fait que je vais probablement laisser tomber ce système : trop compliqué à maintenir, trop d'ennui pour l'utilisateur maladroit, trop facile à contourner.

edit je vais donner un exemple de mon ancien système :

un visiteur arrive sur mon site, je lui initialise une session, il reçoit nb_pages_vues : 1 dans son cookie, et je note.
Il visite 9 autres pages, je le reconnais à chaque fois, et suite aux incrémentations il a nb_pages_vues = 10 dans son cookie, et dans ma base de donné SQL j'ai la même chose.
Un pirate copie son cookie.

=> l'utilisateur revisite une page, je lis nb_pages_vues = 10 dans son cookie et dans ma table SQL => ok, il reçoit 11.
=> le pirate essaie avec nb_pages_vues = 10, ca colle pas => busted reset session.
OU
=> si le pirate visite la page avant l'utilisateur, ca colle pour lui
=> l'utilisateur visite la page après le pirate, ca colle pas, busted reset session.

[manticore]

=> l'utilisateur revisite une page, je lis nb_pages_vues = 10 dans son cookie et dans ma table SQL => ok, il reçoit 11.
=> le pirate essaie avec nb_pages_vues = 10, ca colle pas => busted reset session.
OU
=> si le pirate visite la page avant l'utilisateur, ca colle pour lui
=> l'utilisateur visite la page après le pirate, ca colle pas, busted reset session.

Oui ça doit marcher, l'attaquant doit alors se placer en position de mitm ce qui est un poil plus difficile. Ce qui veut dire que toutes les connexions de ta cible vont transiter par l'attaquant qui va effectuer les requêtes pour sa cible.

Ou alors de paralyser sa cible avec un déni de service, ou en le déconnectant de son point d'accès.

Mais c'est vrai que c'est astucieux (p.s. je connais pas de site qui pratique ce genre de système, si tu en connais 1 je suis preneur).

Par contre ça l'air un peu lourd pour l'utilisateur, un reset de session si tu fais deux refreshs...

Quand je n'ai pas de cookie, j'initialise une nouvelle session (j'envoie un cookie visiteur).
Une attaque efficace avec un système SQL de session, et beaucoup moins efficace avec un système cookie de session, c'est flooder de requete en supprimant ses cookies : le site va créer énormément de sessions.

Oui tu risques une attaque par déni de services, dans ce cas. Mais il faudrai voir les ressources que cela consomme vraiment...

Il est impossible de vérifier si un utilisateur accepte ou non un cookie : un script malicieux peut accepter le cookie, et l'effacer directement : je ne le remarquerai pas à la prochaine requete.

Oui, le cookie est géré par un navigateur, si tu scripts, en général tu ne t'amuses pas à récupérer les cookies mise à part si tu les utilises.

[Doonge]

Mes sites perso utilisaient ce type de "protection", mais je la crois plus gênante qu'utile au final.

Et il n'est pas obligatoire d'être mitm, si tu sniffe le réseau tu vois bien quand ta victime arrête de visiter le site, et là tu peux continuer sa session avec le cookie que tu as volé, rendant inefficace cette protection.


Je parcours de temps à autre les codes sources des portails opensource, je n'ai pas observé ce type de code, mais à l'époque ceux-ci stockaient les adresses IP donc bon ...


edit : un avantage d'utiliser une base SQL c'est que tu as une idée de la charge serveur (en connaissant le nombre de sessions actives). Et tu peux limiter le nombre maximum de sessions actives pour passer en mode économique (interdire l'accès aux visiteurs non-membre sauf à une page économique de "login").

[manticore]

j'ai réfléchit à ton idée avec un ami, et on est arrivé à une solution beaucoup plus élégante est simple à mettre en oeuvre :

Tu utilises les sessions php standard. Cela va t'éviter des heures de codes.

Tu ajoutes un cookie avec une valeur aléatoire, à chaque visite tu renvois une nouvelle valeurs aleatoire au client.

Si la valeur reçu pour une sessions est différentes de celle qui est stocké tu détruis la sessions.

C'est pas lourd, simple à mettre en place. Cela protège des logiciels standard donc des scripts kidies.

Ca reste une solution contournable si tu es en position de mitm, mais c'est un plus qui coûte pas cher je le mettrai peut-être sur mon site qui sait...

Si tu trouves une fonctionnalité de plus que ton système a, et que le mien n'a pas n'hésite pas à m'en faire part.

[Doonge]

Ca ne me dérange pas de passer des heures à coder, c'est pour ça que coder est un hobby pour moi (enfin, de temps à autres).

Je n'aime pas les sessions php standard, pour diverses raisons qui sont déjà documentées sur le net (écriture dans un fichier accessible par défaut sur tout le serveur sur mutualisé, pas d'écriture SQL par défaut, identifiant de session SESSID qui m'est inutile ...). Je ne dis pas qu'elles sont mauvaises, mais il faut les configurer un minimum, ce qui implique au final de quand même écrire ses propres fonctions.

La valeur aléatoire ne m'intéresse pas (ça ne change rien au compteur, si ce n'est que ça prend plus de ressources de générer un string aléatoire) puisqu'on a déjà débattu des inconvéniences de l'unicité d'une session (hors SSL).

Je ne connais pas ton système (ou alors c'est celui que tu as décris avec sessions de base et valeur aléatoire changée à chaque requete ?), mais les "avantages" (les différences) du mien ont été évoqués ici ^^

Je donnerai des nouvelles quand j'aurai avancé.

[lucas74]

j'ai réfléchit à ton idée avec un ami, et on est arrivé à une solution beaucoup plus élégante est simple à mettre en oeuvre :

Tu utilises les sessions php standard. Cela va t'éviter des heures de codes.

on est d'accord

Tu ajoutes un cookie avec une valeur aléatoire, à chaque visite tu renvois une nouvelle valeurs aleatoire au client.

Si la valeur reçu pour une sessions est différentes de celle qui est stocké tu détruis la sessions.

et en cas de double clic comme expliqué plus haut ? Le serveur regénère un identifiant mais c'est trop tard, une nouvelle requête arrive avec un identifiant déjà périmé.. Pas terrible..

[gene69]

les sessions php standard, pour diverses raisons qui sont déjà documentées sur le net (écriture dans un fichier accessible par défaut sur tout le serveur sur mutualisé, pas d'écriture SQL par défaut, identifiant de session SESSID qui m'est inutile ...). Je ne dis pas qu'elles sont mauvaises, mais il faut les configurer un minimum, ce qui implique au final de quand même écrire ses propres fonctions.

J'ai toujours tendance à penser que lorsqu'on n'utilise pas les primitives du langage, c'est qu'on pose mal la question et qu'on essai de répondre mal à une question mal posée. Car enfin, à quoi peut-il servir de remettre en cause un système qui est rodé depuis des années, qui est maîtrisé (je veux dire qu'on en connait bien les défauts et les faiblesses)? Je veux bien croire qu'il faut du progres mais enfin:

->le systeme actuel est entierement surchargeable en php (tous les handlers)
-->free utilises des sessions dans le répertoire utilisateurs
-->d'autres utilises un répertoires commun avec des users différent et des droits 700 sur les fichiers
-->d'autres (amen?) utilisent des bases de données...
Les trois sont tres difficiles à violer.
-> le coockies de session, c'est génial ça évite d'avoir à transferer un username et un password à chaque échange... perso je dirai pas "je n'en ai pas besoin", je dirai plutôt "je n'ai besoin QUE de ça".

Le vol de session php ... mouais c'est pas comme si c'était un problème entierement résolu par HTTPS. Sniffer du HTTPS vous verrez.

[manticore]

Le vol de session php ... mouais c'est pas comme si c'était un problème entierement résolu par HTTPS. Sniffer du HTTPS vous verrez.

Il me semble qu'il est possible de faire un mitm et d'usurper une sessions https non ? Je l'ai jamais tester, mais je suis quasi sur que c'est possible.

quelques sources trouvées en 1 minutes sur google:
http://www.contentverification.com/man-in-the-middle/

http://www.informit.com/guides/conte...ity&seqNum=258

[Doonge]

@lucas74
Moi pas.

@gene69
effectivement le système actuel est surchargeable (les session handler), et précisément c'est ce que je fais même avec une méthode cookie.
Après tout, un cookie c'est juste un endroit de stockage, qui est une des composantes des sessions.
Ce contre quoi je m'opposais, c'était le fait d'utiliser tel quel les sessions de php (sans les handler, donc). Je suis pas bête au point d'éviter d'utiliser des fonctions natives (qui sont à mon avis plus rapides).
Il m'a semblé comprendre que mon interlocuteur du moment me conseillait de pas me casser la tête même avec les fonctions session_handler, conseil que je n'apprécie pas.

Au sujet du problème de vol de session résolu complètement ou non par le HTTPS, ce qui m'intéresse de savoir c'est que cela demande beaucoup plus de moyen. Je ne sais pas si l'inviolabilité existe, mais la difficulté pour "casser" la sécurité est un facteur intéressant.
Au final, utiliser ou non SQL, utiliser ou non les cookies, n'a pas d'incidence sur le niveau de sécurité hors HTTPS, et c'est ce que je voulais savoir.