SessionID faken

[Michi]

Hallo Forum,
bei einem Loginverfahren speichere ich in die SessionID (Tomcat) ein (User-)Objekt, falls die Logindaten in Ordnung waren. (User ist authentifiziert)

Auf den folgenden Seiten überprüfe ich dann nach jedem Klick, ob in der SessionID nur ein (User-)Objekt vorhanden ist. Falls ja, ist er weiterhin authentifiziert.

Meine Frage lautet gerade nun, da ich mich noch nicht mit Tomcat befasst habe und nicht genau weiß, die wie SessionID-Verwaltung abläuft, ob man generell SessionID's faken kann, da der User die SessionID ja über die Adresszeile sieht, bzw. über die Verlinkunen mitgenommen werden.

Grüße

[hotti]

hi,

Meine Frage lautet gerade nun, da ich mich noch nicht mit Tomcat befasst habe und nicht genau weiß, die wie SessionID-Verwaltung abläuft, ob man generell SessionID's faken kann, da der User die SessionID ja über die Adresszeile sieht, bzw. über die Verlinkunen mitgenommen werden.

Wenn's doof programmiert ist ja. heise hat mal über sowas geschrieben und auch darüber, dass es User gibt, die Links verschicken, mit Session-Ids drinne.

Will meinen, das hat primär nichts mit Serversoftware und Programmiersprache zu tun.

Erste Abhelfe: Einen Session-Key nur für den Verlauf einer Browsersitzung gültig zu machen und ein Zeitlimit setzen.

Hotte

[Michi]

Hi,

Will meinen, das hat primär nichts mit Serversoftware und Programmiersprache zu tun.

Erste Abhelfe: Einen Session-Key nur für den Verlauf einer Browsersitzung gültig zu machen und ein Zeitlimit setzen.

Session-Key höre ich jetzt zum ersten Mal. Danke für den Tipp, ich informiere mich die Tage mal diesbezüglich.

Was mir jetzt aber spontan eingefallen ist. Ich speichere in die Session beim Login auch die IP (oder sonst was) von dem User (zusätzlich zum (User-)Objekt), der sich eingeloggt hat. In den nächsten Seiten prüfe ich die Autorisierung, indem ich nicht nur prüfe, ob ein (User-)Objekt in der SessionID ist, sondern hole von der SessionID die IP und hole die aktuelle IP der Anfrage und vergleiche, ob diese identisch sind.

Dafür müsste ich noch die Session-Verwaltung vom Tomcat anschauen. Wie er die SessionID erzeugt, wie er es einem Benutzer zuweist, wo er es speichert/abfrägt, wo und wie die Zusatzinformationen gespeichert werden, die in die Session eingefügt werden. Hoffentlich finde ich da die Tage etwas verständliches (vorallem deutsches :-))

Grüße

[hotti]

hi,

mit dem Session-Zeugs wird meistens ein Cookie verwendet, das geht im Prinzip so, Beispiel am Login:

User Pilgrim kriegt ein Formular zum Einloggen und gibt seine Credentials (name, passw) ein. Das kommt am Server an und wird geprüft.

Ist der User authentifiziert, wird serverseitig ein zufälliger String erzeugt, der idealerweise einmalig ist, das ist der sog. Session-key (SK). Der SK wird nun einmal serverseitig gespeichert und mit der Antwortseite an Pilgrim wird ein Cookie mit dem SK geschickt, Pilgrims Browser speichert den SK somit auf der Festplatte.

Damit ist die Session established. Alles was Pilgrim nun nach dem Login macht (Daten löschen, Daten verändern, Daten hinzufügen...) ist eine Interaktion zwischen dem Browser und dem Server wo nur noch geprüft wird, ob der Key, der mit dem Cookie vom Browser mitkommt, in der Datenbank auf dem Server vorhanden ist und mit diesem übereinstimmt.

Session-Klau: Susa kommt irgendwie an Pilgrims Rechner, die Sitzung ist noch offen und so kann Susa den SK aus dem Cookie lesen. Susa könnte den Key nun nehmen und damit Mist machen... Hieran wird bereits deutlich, dass ein einzelner SK nicht reicht um einem solchen, ansich banalen Unfall vorzubeugen. Es gibt jedoch weitere Möglichkeiten, Interesse?

Hotte

[utelbursch]

vorzubeugen. Es gibt jedoch weitere Möglichkeiten, Interesse?

Hotte

JA!

[hotti]

hi,

»» vorzubeugen. Es gibt jedoch weitere Möglichkeiten, Interesse?
JA!

Erstmal folgende Feststellung: Alles was nach dem Login einschließlich Sessionkey SK vom Browser zum Server geschickt wird, um zu prüfen ob die Session ok ist, kann geklaut und nachgebildet werden. Es hat also wenig Sinn, außer dem SK noch den UserAgent (ob IE, Mozi, FF...) oder irgendwelche Daten aus versteckten Formularfeldern zu übertragen.

Schauen wir mal weiter, was es noch so gibt.

HTTPS (SSL): Gute Idee, die Übertragung ist verschlüsselt, Klau des SK auf dem Ü-Weg nicht möglich.

IP-Adresse: Sofern sich diese nach einem Login nicht ändert, könnte die außer dem SK den Endrechner identifizieren, zumindest für die Dauer einer Session. Sind Proxyserver im Spiel, könnte es sein, dass sich die IP-Adresse noch innerhalb einer Session ändert (round robin-Proxies) oder dass mehrere User mit dergleichen IP-Adresse, nämlich mit der des Proxies vertreten sind. Hier wäre die Variable HTTP_X_FORWARDED_FOR von Interesse, die auf einem Proxy (squid) gesetzt werden sollte und die IP-Adresse des eigentlichen Requesters durchreicht.

Session zeitlich begrenzen: Auf jeden Fall. UND Abgelaufene SK's löschen.

Dem User können wir auch noch was aufbrummen: er soll bitteschön seinen PC nach dem Einloggen nicht unbeaufsichtigt lassen und sich nach Arbeitsende von der Anwendung ausloggen, so dass der Session-Key sofort gelöscht wird.

Hotte

[Tom]

Hello,

Session zeitlich begrenzen: Auf jeden Fall. UND Abgelaufene SK's löschen.

besser nicht sofort löschen. SKs sind mMn Wegwerfschlüssel oder werden zumindest über einen weiten Zeitbereich nicht wiederverwendet. Wenn also morgen schon einer damit angedackelt kommt, könnte man nachschauen, ob der Schlüssel bereits verbraucht ist.

Das erhöht die Sicherheit.

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[hotti]

Hello Tom,

»» Session zeitlich begrenzen: Auf jeden Fall. UND Abgelaufene SK's löschen.

besser nicht sofort löschen. SKs sind mMn Wegwerfschlüssel oder werden zumindest über einen weiten Zeitbereich nicht wiederverwendet. Wenn also morgen schon einer damit angedackelt kommt, könnte man nachschauen, ob der Schlüssel bereits verbraucht ist.

Das erhöht die Sicherheit.

Oder eher den Programmieraufwand? Ich kann mir schon denken, worauf Dein berechtigter Einwand abzielt: Dass es niemals gelingen wird, einen auf der Welt absolut einmaligen Sessionkey zu erzeugen.

Grüß mir den Berg,
Hotte

[Michi]

Hi,
da hat schon jemand mit Ja geantwortet für mich :-)

Erstmal folgende Feststellung: Alles was nach dem Login einschließlich Sessionkey SK vom Browser zum Server geschickt wird, um zu prüfen ob die Session ok ist, kann geklaut und nachgebildet werden. Es hat also wenig Sinn, außer dem SK noch den UserAgent (ob IE, Mozi, FF...) oder irgendwelche Daten aus versteckten Formularfeldern zu übertragen.

Hab nach SessionKeys SK mal gegoggelt, aber nichts gefunden. Vom Prinzip her dürfte es doch dasselbe (ähnlich) wie die SessionID Verwaltung vom Webserver sein oder? Entweder schleif man die SessionID über die Adresszeile immer mit oder der Webserver schickt es an den Browser und der Browser speichert es dann als Cookie. Wie auch immer.

Schauen wir mal weiter, was es noch so gibt.

HTTPS (SSL): Gute Idee, die Übertragung ist verschlüsselt, Klau des SK auf dem Ü-Weg nicht möglich.

IP-Adresse: Sofern sich diese nach einem Login nicht ändert, könnte die außer dem SK den Endrechner identifizieren, zumindest für die Dauer einer Session. Sind Proxyserver im Spiel, könnte es sein, dass sich die IP-Adresse noch innerhalb einer Session ändert (round robin-Proxies) oder dass mehrere User mit dergleichen IP-Adresse, nämlich mit der des Proxies vertreten sind. Hier wäre die Variable HTTP_X_FORWARDED_FOR von Interesse, die auf einem Proxy (squid) gesetzt werden sollte und die IP-Adresse des eigentlichen Requesters durchreicht.

Stimmt, an Proxies hatte ich nicht gedacht.

Von unserem Professor habe ich heute auch erfahren, dass ich Loginverfahren niemals selber realisieren soll, sprich Passwörter in DB.s speichern und um die Authentifizierung kümmern, sondern dem Webserver überlassen. (Für Tomcat gäbe es da irgendwelche Security-Einstellungen - Irgendwas mit Rollen)

Grüße
Michi

[hotti]

moin Michi,

Von unserem Professor habe ich heute auch erfahren, dass ich Loginverfahren niemals selber realisieren soll, sprich Passwörter in DB.s speichern und um die Authentifizierung kümmern, sondern dem Webserver überlassen. (Für Tomcat gäbe es da irgendwelche Security-Einstellungen - Irgendwas mit Rollen)

Jow, häng Dich dran und frag den Prof. mal richtig aus.... Kryptozeugs ist ein interessantes Thema.

Viele Grüße,
Horst Haselhuhn

[Michi]

morgen hotti,

Jow, häng Dich dran und frag den Prof. mal richtig aus.... Kryptozeugs ist ein interessantes Thema.

ja werde ich nächsten Mittwoch machen. Der einzige Nachteil beim Überlassen der Authentifizierung auf den Webserver ist es, dass man kein Loginformular auf der Webseite hat, sondern ein unformatiertes Popup erscheint.

Grüße

[hotti]

morgen hotti,

moin,

»» Jow, häng Dich dran und frag den Prof. mal richtig aus.... Kryptozeugs ist ein interessantes Thema.

ja werde ich nächsten Mittwoch machen. Der einzige Nachteil beim Überlassen der Authentifizierung auf den Webserver ist es, dass man kein Loginformular auf der Webseite hat, sondern ein unformatiertes Popup erscheint.

Achso, der meint die Auth. per Status 403.... bleib dran Michi. Du wirst ein interessantes Betätigungsfeld finden.

Hotte

[Alexander (HH)]

Moin Moin!

IP-Adresse: Sofern sich diese nach einem Login nicht ändert, könnte die außer dem SK den Endrechner identifizieren, zumindest für die Dauer einer Session. Sind Proxyserver im Spiel, könnte es sein, dass sich die IP-Adresse noch innerhalb einer Session ändert (round robin-Proxies) oder dass mehrere User mit dergleichen IP-Adresse, nämlich mit der des Proxies vertreten sind. Hier wäre die Variable HTTP_X_FORWARDED_FOR von Interesse, die auf einem Proxy (squid) gesetzt werden sollte und die IP-Adresse des eigentlichen Requesters durchreicht.

Es war lange Zeit so, dass AOL-User für jeden Request über einen anderen Proxy geleitet wurden. Ich weiß nicht, ob das immer noch so ist, aber wenn man eine konstante IP-Adresse während einer Session voraussetzt, wird man konstant Ärger mit AOL-Usern haben, die sich nicht anmelden können.

Der X-Forwarded-For-Header kann natürlich beliebig gefälscht werden, und nicht jeder Proxy fügt diesen Header ein. Ich halte diesen Header für sehr problematisch, weil er Informationen über das eigentlich geschützte Netzwerk hinter dem Proxy preisgibt. Wenn man sich darauf einläßt, X-Forwarded-For zu prüfen, dann sollte man tunlichst darauf achten, dass der Header von Anfang an da ist. Sonst könnte ein Angreifer die gesamte IP-Adressen-Prüfung aushebeln, einfach indem er einen X-Forwarded-For-Header mitschickt.

Alexander