Kommentare zu: Session Hijacking verhindern

Von: mein gott und meine welt » Session Fixation verhindern «

mein gott und meine welt » Session Fixation verhindern « — Thu, 19 Nov 2009 21:12:47 +0000

[...] gestolpert bin – es gibt sie noch immer – auch in neuen Seiten. Was ich in “Session Hijacking verhindern” geschrieben habe, war zwar nicht kompletter Unsinn, aber der Punkt 4… naja… ein [...]

Von: cortex

cortex — Tue, 03 Nov 2009 06:59:02 +0000

habe nochmal über punkt 4 nachgedacht… die methode bringt imho nichts: ein user wird nach wie vor über eine eindeutige id identifiziert – bspw. das session-cookie. dies wäre dann auch die id des dazugehörigen datensatzes. mit der übernahme der session durch den angreifer wird also auch die session-id-history übernommen.
das grundlegende problem bleibt die (eindeutige) identifizierung des users auf grundlage einer session. es spielt keine rolle, was und wieviel ich drumherum baue… das ganze wird einfach nicht sicherer. um es mal mit esser’s worten auszudrücken: (siehe verlinkung in post 11): “das session-system von php kann mit einfachen mitteln sicherer gemacht werden, ein kompletter Schutz ist aber nahezu unmöglich.”

Von: ich

ich — Thu, 29 Oct 2009 11:38:26 +0000

Leider hatte ich noch keine Zeit um meine Hirnwindungen zu entwirren, um den Punkt 4 einmal genau zu prüfen, sobald ich dies erledigt habe kommt natürlich das Kondensat dazu. :O)

Von: Florian

Florian — Thu, 29 Oct 2009 10:56:29 +0000

Vielen Dank für diesen aufschlussreichen Post. Toll dass es durch Solche die Möglichkeit gibt, sich “passiv” weiterzubilden.

Sollte Ansatz 4 nicht den gewünschten Effekt haben wäre es gut, wenn der Post entsprechend geändert wird

Wie du schon richtig im StudiVZ-Post vermutest lesen nicht Alle die Kommentare mit.

Vielen Dank!
Florian

Von: cortex

cortex — Tue, 27 Oct 2009 12:40:45 +0000

hier ein link zum kapitel “session” in “php sicherheit” von s. esser: http://www.dpunkt.de/leseproben/3-89864-369-7/Kapitel_7.pdf

punkt 4 deiner liste erinnert mich nämlich ein bissel an das “page ticket system”… bin allerdings auch noch nicht dazu gekommen / habe nicht nochmal daran gedacht, deine idee zu überdenken .-

Von: ich

ich — Tue, 27 Oct 2009 09:15:21 +0000

Da muss ich wohl noch einmal in mich gehen und ein PoC basteln, evtl. ist es ja doch unsinnig was ich da gedacht habe.

Von: wolph

wolph — Mon, 26 Oct 2009 09:59:51 +0000

Punkt 4 check ich nicht. Ein Session-Hijacker wird doch versuchen sein Opfer so gut wie möglich zu imitieren, sprich all die geklauten Cookies an den Server schicken und doch keine die er vorher selber gesammelt hat. Wie erkennt man denn da, dass der Angreifer vorher die Session-ID 345678 gehabt hat?

Von: ich

ich — Sat, 24 Oct 2009 11:43:51 +0000

Punkt 2 hatte ich nur für StudiVZ aufgelistet, da diese Methode dort, mit den bekannten Schwächen, im Einsatz ist. ;O)

Punkt 3 fand ich im Netz, welcher mich aber auch nicht so wirklich überzeugte, deswegen Punkt 4.

Mein Favorit ist bestimmt nicht neu, aber zumindest konnte ich dazu im Netz nichts finden.

Von: cortex

cortex — Sat, 24 Oct 2009 09:29:24 +0000

zu 1: die idee ist nicht schlecht (obgleich etwas wacklig). die schwäche der methode nennst du ja selbst.

zu 2: bitte nicht – diese “sicherheitsmasznahme” wurde bereits x mal (in den foren dieser welt) diskutiert und als wertlos – da unpraktikabel – eingestuft.

zu 3: session_regenerate_id schützt NICHT gegen session hijacking. wer die serverseitige id-regen auslöst (legitimierter user oder angreifer) ist banane. als schutz gegen session Fixation allerdings gut zu gebrauchen; wird i.d.r. nach einem erfolgreichen user-login durchgeführt.

zu 4: interessant…

Von: Michael Kostic

Michael Kostic — Fri, 23 Oct 2009 16:31:46 +0000

Aarrrg….!

Grün, grün, grüner als grün!

Piiiiiieeep, britzel, knatter, knatter:

2
+
2
=
3,988795

Da können wir ja schon fast von 4 ausgehen.

Gut Müller, machen Sie es so!