page de connexion utilise le protocole SSL, les pages non chiffrées ne voient pas cookie de session cryptée (Grails, Acegi)

Question

Configuration: Grails 1.1, Acegi/plug-in Spring Security

Je veux les utilisateurs de se connecter via le protocole SSL, donc je dois '/ login/**' dans ma liste channelConfig.secure [], mais presque tout le reste est dans channelConfig.insecure []. Chaque requête pour/login est redirigée vers https: // et toutes les autres requêtes sont redirigées vers http: //. Mon problème est que le processus de connexion définit le cookie sur "Envoyer uniquement les connexions cryptées", donc lorsque la page de connexion redirige vers/home, la page d'accueil ne voit pas le cookie et me redirige vers la page de destination . Lorsque j'essaie de me reconnecter, la page de connexion voit le cookie et me redirige ... etc.

J'ai cherché à travers this page about SecurityConfig pour voir s'il y avait une option pour permettre aux cookies créés via SSL d'être lus par HTTP non crypté, mais je n'ai rien trouvé. Y a-t-il une option que je peux définir pour rendre mon cookie de connexion disponible pour mes contrôleurs non cryptés?

Answer 1

Ce serait une vulnérabilité.

Tout man-in-the-middle qui peut voir le cookie de session serait en mesure de faire des demandes en tant qu'utilisateur. C'est presque aussi mauvais que le mot de passe étant intercepté. L'homme-in-the-middle ne serait pas en mesure d'établir de nouvelles sessions de son propre chef, mais il serait en mesure de faire quoi que ce soit, l'utilisateur peut faire une fois qu'un utilisateur se connecte à.

---

En utilisant SSL fait un beaucoup plus que simplement cacher le nom d'utilisateur et mot de passe lors de la connexion. Tout d'abord, il assure la confidentialité de tous les messages entre le client et le serveur. Il est facile de reconnaître le mot de passe en tant que données sensibles, mais les fonctionnalités de l'application peuvent également ne pas être aussi évidentes. Il est plus sûr et plus facile de protéger les entrées utilisateur et le contenu généré dynamiquement que d'essayer d'évaluer soigneusement les problèmes de confidentialité de chaque champ de données utilisé dans votre application. Le contenu statique tel que les images, les pages d'aide, etc., n'est probablement pas aussi sensible, mais en analysant les demandes pour ce contenu, un attaquant pourrait avoir une bonne idée de ce qu'un utilisateur fait sur le site.

Deuxièmement, le protocole SSL assure l'intégrité de chaque requête. Cela empêche un attaquant de modifier ou d'ajouter sa propre entrée néfaste aux demandes des utilisateurs, ou de modifier les résultats produits par le serveur.