Was wird in der Java Servlet-API getan, um sicherzustellen, dass die Sitzungs-ID einer Person nicht gestohlen wird?Was verhindert, dass die ID von HttpSession gestohlen wird?
Zum Beispiel, wenn ich eine aktive Sitzung hatte und jemand meine Sitzungs-ID irgendwie festhielt, konnten sie sie benutzen?
Nichts verhindert es. Sie erhalten die Sitzungs-ID, Sie können an der Sitzung teilnehmen.
Im üblichen Fall von Cookies ist dies kein Risiko für sich. Der Angreifer sollte nicht in der Lage sein, ein Benutzer Session-Cookie zu lesen, es sei denn:
sie Man-in-the-Middle-Fähigkeit haben, in welchem Fall Sie haben viel schlimmere Probleme als nur Session-IDs;
Sie haben eine Cross-Site-Scripting-Lücke hinterlassen. In diesem Fall haben Sie viel schlechtere Probleme als nur Sitzungs-IDs.
Sie sind anfällig für DNS-Rebinding/Cross-Domain-Cooking-Angriffe, in diesem Fall sollten Sie es beheben, indem Sie nur bekannte gute Host: Anfragen zulassen.
(Während Sie binden Sitzungen versuchen können IP-Adressen, riskiert dies durch gültige Sitzungen brechen Round-Robin-Proxies zB. IPs als Teil einer breiter angelegten Strategie zur Erkennung verdächtiger Aktivitäten verwendet werden kann, aber in der Öffentlichkeit Internet ist es nicht eine gute Idee immer jede Anforderung in einer Sitzung von der gleichen IP zu kommen.)
Leider in Servlet gibt es einen anderen Fall, abgesehen von Cookies: jsessionid= Parameter. Da sie in der URL selbst erscheinen, macht das sie viel mehr undicht (zB über Referrer und eingefügte Links). Und das ist bei weitem nicht das einzige praktische Problem mit Parametersitzungs-IDs. Sie vermasseln Navigation und Wrack SEO.
Meiner Meinung nach jsessionid= URLs sind einer der schlimmsten frühen Fehler Servlet, eine diskreditierte Cookie-Fallback-Strategie von gestern, die für nichts verwendet werden sollte. Aber sicherlich sollten sie keinen Zugang zu privilegierten Daten gewähren dürfen; Verwenden Sie stattdessen die HTTP-Standardauthentifizierung, wenn Sie einen Ausweichmechanismus für Browser benötigen, die keine Cookies unterstützen.
In Servlet 3.0 können Sie problemlos jsessionid= URLs mit <session-config> in der web.xml deaktivieren; Leider haben Sie in früheren Versionen noch mit Filtern herumgespuckt, wenn Sie das Feature richtig deaktivieren wollen.
Ja, sie könnten es verwenden. Nichts wird getan, um es zu schützen, es sei denn, Sie stellen Ihren gesamten Datenverkehr über SSL.
Dies ist, wie Firesheep funktioniert, die vor kurzem eine Menge Aufmerksamkeit für den einfachen Diebstahl von Sessions bekommen hat.
Ist die Übertragung aller Daten über HTTPS wirklich die einzige Lösung? Gibt es keine Frameworks oder bekannte Problemumgehungen? Und selbst wenn alle Daten über HTTPS übertragen werden, könnte jemand kein Programm schreiben, um eine Session ID zu erraten? –
Ja, es ist möglich, dass alle Informationen, die Sie an den Benutzer senden, um sie zurückzusenden, abgefangen werden können, so dass die Verschlüsselung die einzige Möglichkeit ist, sie zu stoppen. Was das Erraten angeht, so sind Session-IDs normalerweise so entworfen, dass sie schwer zu erraten sind, dass dies nicht praktikabel ist. –
Ja, die Sitzungs-ID gibt jemandem Zugriff auf die entsprechende Sitzung.
Sie können die IP-Adresse speichern, die während der Anmeldung in der Sitzung verwendet wird, und wenn die IP-Änderungen erforderlich sind, muss sich der Benutzer erneut anmelden. Zusätzlich (nicht sicher, ob das automatisch gemacht wird) könnten Sie das gleiche für den User Agent tun - nicht wirklich die Sicherheit vor bösartigen Attacken erhöhen, sondern nur gegen dumme Benutzer, die versehentlich ihre SessionID verraten, wenn sie über GET und nicht über einen Cookie weitergegeben werden.
+1 für die Session-Konfiguration in Servlet 3.0 – Bozho