135 votes

Quel est le meilleur moyen d'empêcher le détournement de session ?

Cela concerne plus particulièrement l'utilisation d'un cookie de session client pour identifier une session sur le serveur.

La meilleure solution consiste-t-elle à utiliser le cryptage SSL/HTTPS pour l'ensemble du site web, ce qui vous donne la meilleure garantie qu'aucune attaque de type "man in the middle" ne sera en mesure de renifler un cookie de session client existant ?

Et peut-être la deuxième meilleure solution est-elle d'utiliser une sorte de cryptage de la valeur de session elle-même qui est stockée dans votre cookie de session ?

Si un utilisateur malveillant a un accès physique à une machine, il peut toujours consulter le système de fichiers pour récupérer un cookie de session valide et l'utiliser pour détourner une session ?

9voto

Hubert Points 831

Essayez le protocole Secure Cookie décrit dans ce article de Liu, Kovacs, Huang et Gouda :

Comme indiqué dans le document :

Un protocole sécurisé cookie sécurisé qui s'exécute entre un client et un serveur doit fournir les quatre services suivants : authentification, confidentialité, intégrité et anti-rejeu.

Quant à la facilité de déploiement :

En termes d'efficacité, notre protocole n'implique pas de consultation de base de données ni de cryptographie à clé publique. base de données ou de cryptographie à clé publique. En termes de déploiement, notre protocole peut être facilement déployé sur un serveur web existant, et il ne nécessite aucune modification de la spécification des cookies Internet. la spécification des cookies Internet.

En bref : il est sûr, léger, et fonctionne parfaitement pour moi.

9 votes

Votre lien est une spécification du protocole - avez-vous un lien vers une implémentation ? Ce serait formidable - merci.

5voto

Hatch Points 130

Il existe de nombreuses façons de créer une protection contre le détournement de session, mais toutes réduisent la satisfaction des utilisateurs ou ne sont pas sûres.

  • Contrôles d'IP et/ou de X-FORWARDED-FOR. Ces contrôles fonctionnent et sont assez sûrs... mais imaginez la douleur des utilisateurs. Ils arrivent dans un bureau avec du WiFi, ils obtiennent une nouvelle adresse IP et perdent la session. Ils doivent se reconnecter.

  • Vérification de l'agent utilisateur. Comme ci-dessus, une nouvelle version du navigateur est sortie, et vous perdez une session. De plus, ils sont très faciles à "pirater". Il est trivial pour les pirates d'envoyer de fausses chaînes d'UA.

  • jeton localStorage. Lors de la connexion, un jeton est généré, stocké dans la mémoire du navigateur et stocké dans un cookie crypté (crypté du côté du serveur). Cela n'a aucun effet secondaire pour l'utilisateur (localStorage persiste lors des mises à jour du navigateur). Ce n'est pas aussi sûr - car il s'agit simplement d'une sécurité par l'obscurité. En outre, vous pourriez ajouter une certaine logique (cryptage/décryptage) au JS pour le rendre encore plus obscur.

  • Réédition des biscuits. C'est probablement la bonne façon de procéder. L'astuce consiste à n'autoriser qu'un seul client à utiliser un cookie à la fois. Ainsi, le cookie d'un utilisateur actif sera réémis toutes les heures ou moins. L'ancien cookie est invalidé si un nouveau est émis. Les piratages sont toujours possibles, mais beaucoup plus difficiles à réaliser - soit le pirate, soit l'utilisateur valide se verra refuser l'accès.

4voto

Kibbee Points 36474

Assurez-vous que vous n'utilisez pas d'entiers croissants pour les identifiants de session. Il est préférable d'utiliser un GUID ou une autre longue chaîne de caractères générée de manière aléatoire.

3voto

Jzf Points 70

A priori, l'objet de session n'est pas accessible au client, car il est stocké sur le serveur web. Cependant, l'identifiant de session est stocké sous forme de cookie et permet au serveur web de suivre la session de l'utilisateur.

Pour empêcher le détournement de session à l'aide de l'identifiant de session, vous pouvez stocker une chaîne hachée à l'intérieur de l'objet de session, réalisée à l'aide d'une combinaison de deux attributs, remote addr et remote port, accessibles au serveur Web dans l'objet de requête. Ces attributs lient la session de l'utilisateur au navigateur dans lequel il s'est connecté.

Si l'utilisateur se connecte depuis un autre navigateur ou un mode incognito sur le même système, l'adresse IP restera la même, mais le port sera différent. Par conséquent, lors de l'accès à l'application, le serveur Web attribue à l'utilisateur un identifiant de session différent.

Voici le code que j'ai mis en place et testé en copiant l'identifiant de session d'une session à une autre. Il fonctionne assez bien. S'il y a une faille, faites-moi savoir comment vous l'avez simulée.

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

J'ai utilisé l'algorithme SHA-2 pour hacher la valeur en utilisant l'exemple donné à l'adresse suivante SHA-256 Hachage à baeldung

Nous attendons vos commentaires avec impatience.

0 votes

@zaph Je suis désolé, mais je n'ai pas ajouté la réponse t@oz agpahi nI 'rme ps.o rTrhye, pbouitn tI idsi dnno'tt SaHdAd- 2t heen carnyspwteiro nt oe igtahienr . r eBpu.t Le pfoaicntt tihsa tn oIt wSaHsA -a2b leen ctroy pdteitoenc te iutshaegre. oBfu ta ntohteh efra cuts etrh'ast sIe swsaiso na bilde Ctooo kdieet eicntt ou saangoet hoefr aunsoetrh'esr suessesri'osn ,s eis.sei. o,n sieds sCiooonk ihei jianctkoi nagn oatsh eirn utsheer 'osr isgeisnsailo nq,u eis.tei.o,n .s eIs stieosnt ehdi jmayc ksionlgu taiso ni na ntdh ef oournidg iinta lw oqrukess.t iBount. II atme sntoetd tmhye seoxlpuetrito no na ntdh ifso,u nsdo iIt wwoourlkds .l iBkuet tIh ea mc onmomtu ntihtey etxop ecrhte cokn itfh imsy, asnos wIe rw oiusl dg oloidk ee ntohueg hc. o mMmauynbiet yy otuo ccahne cske ei fw hmayt amnys wceord ei ss ngiopopde te ndoouegsh .a nMda ydbeec iydoeu wchaent hseere iwth aatn smwye rcso dteh es nqiupepsetti odno.e sT haanndk sd!ecidez si cela répond à la question. Merci !

0 votes

@zaph Merci d'avoir signalé l'erreur. J'ai mis à jour ma réponse conformément à votre suggestion. Veuillez retirer votre vote négatif si vous pensez que la réponse est utile.

1voto

davej Points 28

Considérons que pendant la phase de connexion, le client et le serveur peuvent se mettre d'accord sur une valeur de sel secrète. Par la suite, le serveur fournit une valeur de comptage à chaque mise à jour et attend du client qu'il réponde avec le hachage du (sel secret + comptage). Le pirate potentiel n'a aucun moyen d'obtenir cette valeur de sel secret et ne peut donc pas générer le hachage suivant.

3 votes

Mais comment voulez-vous stocker ce sel côté client pour que personne ne puisse le voler ?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X