Attaque par fixation de session

[InstinctHack]

[InstinctHack]

Bon en fait je m'auto-répond

La modification du sid auras plusieurs conséquences :
création d'un nouveau fichier.
"perte" des données de la session précédante (bien qu'on puisse repasser sur l'autre en la renvoyant)

les précautions à prendre sont que le sid soit alphanumériques (en vérité, faut vérifié que le fichier ne remonte pas dans les dossier, ce qui pourrais rendre inaccessible le site) (bien sur ça dépend de la façon dont on stocke les données, j'ai choisi les fichiers )

donc, n'importe qui peux se créer un nouveau sid (bien que vous pouvez faire des tests de longueur/compléxité avant, et même interdire cette pratique en gardant dans un autre fichier les sid que le serveur auras généré, ainsi si un client se pointe avec un sid qui n'en fait pas partie, il se fait recevoir comme il faut )

Et puis comme il est de bonne pratique de regenerer le sid lors d'une élévation de droit et si vous la suivais, l'utilisateur seras obligé de garder ce sid, dans le cas contraire, il perdras tout privilège que l'élévation lui aurais donnée.

Si ça peux en aider d'autres à l'avenir

[InstinctHack]

Au fait j'ai un autre problème maintenant.. Le système marche très bien, tant qu'on as les cookie activés (normal quoi)
En revanche, c'est pas la fête quand on les desactive, en effet un fichier est crée à chaque requete, ce qui fait que le dossier temporaire pour les sessions glonfle :O donc un con qui demande 500 page à la minute auras vite fait de faire planter le système. (je vais faire un système d'anti-dos (ok ça reste de l'applicatif) ) mais le problème est toujours là
J'arrive à detecter les cookie en deux requetes , mais ça change rien, j'ai pensé à garder l'historique des demandes de création de session et limiter la création à une ip toutes les minutes, mais je sais pas... l'idée me plait pas trop... à voir