2009-06-12 6 views
0

Setup: Grails 1.1, Acegi/Spring Security-Plug-inLogin-Seite verwendet SSL, unverschlüsselte Seiten sehen nicht verschlüsselt Session-Cookie (Grails, Acegi)

Ich möchte Benutzer über SSL anmelden, so habe ich '/ login/**' in meiner channelConfig.secure [] Liste, aber fast alles andere ist in channelConfig.insecure []. Jede Anfrage für/login wird zu https: // umgeleitet und jede andere Anfrage wird zu http: // umgeleitet.

Mein Problem ist, dass der Anmeldevorgang den Cookie auf "Nur über verschlüsselte Verbindungen senden" setzt. Wenn die Anmeldeseite nach/home umleitet, sieht die Startseite den Cookie nicht und leitet mich zurück zur Zielseite . Wenn ich mich erneut anmelde, sieht die Login-Seite den Cookie und leitet mich um.

Ich jagte durch this page about SecurityConfig, um zu sehen, ob es eine Option gibt, um über SSL erstellte Cookies zu erlauben, über unverschlüsseltes HTTP gelesen zu werden, aber ich fand nichts. Gibt es eine Möglichkeit, meinen Login-Cookie für meine unverschlüsselten Controller verfügbar zu machen?

Antwort

6

Dies wäre eine Sicherheitslücke.

Jeder Man-in-the-Middle, der den Sitzungscookie sehen kann, kann als Benutzer Anfragen stellen. Dies ist fast so schlimm wie das Abfangen des Passworts. Die Man-in-the-middle nicht in der Lage sein, neue Sitzungen auf seinem eigenen zu etablieren, aber er wäre in der Lage die Benutzer tun können alles in einmal einen Benutzer anmeldet tun.


Verwendung von SSL funktioniert eine viel mehr als nur den Benutzernamen und das Passwort bei der Anmeldung verstecken.

Erstens bietet es Vertraulichkeit für alle Nachrichten zwischen dem Client und dem Server. Es ist einfach, das Passwort als vertrauliche Daten zu erkennen, aber es ist möglicherweise nicht so offensichtlich, welche Anwendungsfunktionen auch sensible Daten verwenden. Der Schutz von Benutzereingaben und dynamisch generierten Inhalten ist sicherer und einfacher als der Versuch, die Datenschutzprobleme jedes in Ihrer Anwendung verwendeten Datenfelds sorgfältig zu bewerten. Statischer Inhalt wie Bilder, Hilfeseiten usw. ist wahrscheinlich nicht so empfindlich, aber durch die Analyse von Anforderungen für diesen Inhalt erhält ein Angreifer möglicherweise eine gute Vorstellung davon, was ein Benutzer auf der Website tut.

Zweitens bietet SSL Integrität für jede Anfrage. Dies verhindert, dass ein Angreifer seine eigene ruchlose Eingabe an Benutzeranforderungen ändert oder anfügt oder die vom Server erzeugten Ergebnisse ändert.

+0

Die Anmeldeseite als einzige verschlüsselte Seite zu haben ist also genauso schlimm wie überhaupt keine Verschlüsselung? Gibt es eine Möglichkeit zu vermeiden, dass Passwörter im Klartext gesendet werden, aber nicht jede Seite verschlüsseln müssen? Wenn nicht, muss ich meinen Ansatz ändern. –

+0

Fast. Sie geben das Passwort nicht preis, was dem Benutzer einige Probleme ersparen könnte, wenn sie dasselbe Passwort auf anderen Seiten verwenden, aber Ihre Site ist vollständig anfällig. Ich habe meine Antwort mit weiteren Informationen aktualisiert. – erickson

+0

Vielen Dank für die umfassende Antwort. Unser Hauptgrund für die Verwendung von unverschlüsselten Verbindungen war die Leistung, aber nach dem Lesen einer anderen Frage über HTTP vs HTTPS-Leistung (http://StackOverflow.com/questions/149274/http-vs-https-performance), denke ich, dass wir nicht ein große Geschwindigkeit es daraus, da fast alle unsere Inhalte dynamisch sind. –

Verwandte Themen