Attaque par fixation de session

[InstinctHack]

Salut,

Toujours sur mon framework, j'essaye de créer mon gestionnaire de session, de la doc j'ai repris ce code :

Code PHP :


class MySessionHandler implements \SessionHandlerInterface
{
        private $savePath;

        public function open($savePath, $sessionName)
        {
                $this->savePath = $savePath;
                if (!is_dir($this->savePath))
                        mkdir($this->savePath, 0777);
                return true;
        }

        public function close()
        {
                return true;
        }

        public function read($id)
        {
                return (string)@file_get_contents($this->savePath.$id);
        }

        public function write($id, $data)
        {
                return file_put_contents($this->savePath.$id, $data) === false ? false : true;
        }

        public function destroy($id)
        {
                $file = $this->savePath.$id;
                if (file_exists($file))
                        unlink($file);
                return true;
        }

        public function gc($maxlifetime)
        {
                foreach (glob($this->savePath.'*') as $file)
                {
                        if (filemtime($file) + $maxlifetime < time() && file_exists($file))
                                unlink($file);
                }
                return true;
        }
}

 

Outre les suppresions d'erreurs dégeulasses, cette ligne me pose quelques soucis de sécurité :

Code PHP :


return (string)@file_get_contents($this->savePath.$id);
 

$id étant le contenu du cookie {session_cookie_name} , bon outre le fait que "../htaccess" supprimerais la totalité du précieux fichier, je me demandais si ça posais pas de problème qu'un utilisateur puisse définir lui-même le SID...
Une attaque par fixation passerais par un lien page.php?PHPSESSID={new_id} mais là, ça me semble pas possible avec du javascript de send un header personnalisé.

Donc un coup de ctype et c'est bon ? où faut empecher l'utilisateur de le modifier en gardant une trace de chaque SID généré et de comparer avant ?

[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