Chaque fois que vous authentifiez, votre application doit modifier l'identifiant de session qu'il utilise. Cela aide à empêcher une personne de mettre en place une session, de copier l'identifiant de session, puis de tromper un utilisateur à l'aide de la session. Étant donné que l'attaquant connaît déjà l'identifiant de la session, ils peuvent l'utiliser pour accéder à la session après que l'utilisateur se connecte, ce qui leur donne un accès complet. Cette attaque a été appelée "fixation de session" entre autres. Comment puis-je modifier l'ID de session une fois que l'utilisateur se connecter au système?
4 Réponses :
Invallamez la session en cours et la nouvelle session:
//invalidate the current session request.getSession().invalidate(); /* get another session and get the ID (getSession()) will create a session if one does not exist */ request.getSession().getId();
Obtenez l'existant; Invalider-le; Créez un nouveau ...
1) Obtenez la session en cours avec httpservletQuest.getsession ();
2) Effacer la session: httpsession.invalidate ();
3) Créez un nouveau: HttpservletQuest.getsession (vrai) ;
Si j'utilise cette méthode, une fois l'utilisateur connecté, il se déconnectera pour régénérer l'ID
Alors que SoLDART a déclaré: "Eh bien, alors c'est une limitation du cadre que vous utilisez, j'ai peur." Pouvez-vous donner un exemple de code de votre processus d'authentification? Cela pourrait aider.
Parler en général (car ce n'est pas un problème de Java, c'est un problème de session de session de session lorsque les identifiants de session sont faciles à découvrir ou à deviner. La méthode principale d'attaque est lorsque l'ID de session est dans l'URL d'une page, par exemple http: // Exemple.com/index?sessionid=123 . Un attaquant pourrait configurer capturer une session puis intégrer le lien dans leur page, tromper un utilisateur à la visiter et faire partie de leur session. Ensuite, lorsque l'utilisateur authentifie la session est authentifié. L'atténuation de cette option est de ne pas utiliser des identifiants de session basés sur l'URL, mais utilisez plutôt des cookies
Certaines applications Web utiliseront une session de cookie basée mais la définition de l'URL initiale, par exemple en visitant http://example.com/index?SessionId=123 verrait l'identifiant de la session dans l'URL, puis créer un cookie de session à partir de celui-ci, définir l'ID dans la session Cookie à 123. L'atténuation est de générer des ID de session aléatoire sur le serveur sans utiliser d'utilisateur d'utilisateur comme une graine dans le générateur.
Il y a aussi des exploits basés sur le navigateur où une mauvaise Le navigateur codé acceptera la création de cookies pour des domaines qui ne sont pas le domaine d'origine, mais il n'y a pas grand chose à faire à ce sujet. Et des attaques de script de sites croisés où vous pouvez envoyer une commande de script dans le site attaqué pour définir le cookie de session, qui peut être atténué en définissant le cookie de session à http_only (bien que Safari n'honore pas ce drapeau)
Pour Java, la recommandation générale est Cependant, à un moment donné sur JBoss, cela n'a pas fonctionné - vous devez donc vérifier ces œuvres comme prévu dans votre framework choisi.
J'essaie d'utiliser cette méthode, mais l'utilisateur sera déconnecté est la session.invalidate () est appelée
Eh bien, alors c'est une limitation du cadre que vous utilisez, j'ai peur.
J'utilise JSF et Tomcat, vous avez donc une autre méthode pour résoudre le problème?
Même la page Owasp a une solution anti-fixation uniquement pour ASP
Eh bien avec ASP.NET, ce n'est pas tellement d'inquiétude, car le processus d'authentification est généralement distinct de la session. Sauf si vous avez roulé le vôtre. Je suppose que JSF stocke des informations d'authentification dans la session, c'est pourquoi l'affiche originale est la réglage perdue lors de la régénération des sessions, mais je ne sais rien de cette plate-forme.
@blowdart: Cela ressemble plus à il ne sauve pas ses informations de session avant d'y invoquer. Cela semble bien sûr être une déconnexion, car toutes les informations utilisateur seront perdues. Voyez ce que Brian a dit de sauver des choses en premier. Et comme il a refusé de poster n'importe quel code lorsque Henrik a demandé, personne ne pouvait l'aider.
Vous êtes toujours sur le serveur pendant que vous invalidez la session.
//get stuff out of session you want before invalidating it.
currentSession = request.getSession(true);
UserProfile userProfile = (UserProfile) currentSession.getAttribute("userProfile");
//now invalidate it
currentSession.invalidate();
//get new session and stuff the data back in
HttpSession newSession = request.getSession(true);
newSession.setAttribute("userProfile", userProfile);
Y a-t-il une raison pour laquelle vous avez posé cela deux fois? Stackoverflow .com / questions / 1138436 / ...
oui je ne peux pas ajouter le commentaire et répondre au message