Pour autant que je sache, lorsque l'utilisateur se connecte à Spring Security invalide la session et en crée une nouvelle.
Donc, si je viens de http avec un cookie sessionID clair, Spring Security devrait définir un nouveau cookie "secure" de sessionID qui sera renvoyé par le navigateur uniquement sur les requêtes https suivantes. Ce qui me manque, c'est que lorsque l'utilisateur 'connecté' passe de https à http, il doit y avoir un cookie sessionID stocké quelque part comme cookie non sécurisé pour garder une trace de la session.
Je ne comprends pas comment Spring gère ça.
Après que l'utilisateur est connecté s'il navigue vers http est alors le clearID sessionID cookie le même que le Secure SessionID et est-il visible au monde? Quelqu'un peut lire cela et détourner la session.
Je ne comprends pas le flux de sécurité de printemps quelqu'un peut-il m'expliquer comment ça marche?
MerciPrintemps Cookies de sécurité après la connexion de l'utilisateur et piratage de session
Répondre
Il est préférable de ne pas mélanger les sessions HTTP et HTTPS pour la raison que vous avez décrite. En fait, il semble se connecter via HTTPS, puis revenir à HTTP ne fonctionnera pas (car le navigateur ne va pas envoyer le cookie de session sécurisée).
[...] sessions créé sous HTTPS, pour lequel la session cookie est marqué comme « sécurisé », ne peut pas ensuite être utilisée sous HTTP. Le navigateur ne renverra pas le cookie au serveur et tout état de session sera perdu (y compris les informations de sécurité ). En commençant d'abord une session en HTTP devrait fonctionner comme le cookie de session ne sera pas marqué comme sécurisé (vous devrez également désactiver session de Spring Security Fixation soutien de la protection pour l'empêcher de la création d'une nouvelle session sécurisée lors de la connexion (vous pouvez toujours créer une nouvelle session vous-même à un stade ultérieur.) Notez que commutation entre HTTP et HTTPS est une bonne idée en général, comme toute application qui utilise le protocole HTTP est vulnérable à l'homme-in the-middle attaques Pour être vraiment sûr, l'utilisateur devrait commencer à accéder à votre site en HTTPS et continuez à l'utiliser jusqu'à ce qu'ils se soient déconnectés . Même en cliquant sur un lien HTTPS à partir d'une page accessible via HTTP est potentiellement risqué.
De http://static.springsource.org/spring-security/site/faq.html