nicht angemeldet
Hello,
Du kannst angreifern das leben schwer machen.
Inwiefern macht das Angreifern das Leben schwer?
Indem die Session-ID schon im nächsten Moment nicht mehr gültig sein kann, da der Eigentümer schneller geklickt hat, als der unrechtmäßige Zweitbesitzer.
Das Ganze ist dann eine Race-Condition.
Das Erraten von konsistenten Sessionnummern wird durch die von MB vorgeschlagene Funktion auf jeden Fall erschwert, denn die gibt es ja dann nicht mehr.
Das Verfahren ist allerdings nicht besonders geschickt, wenn die Webanwendung mit schnellen AJAX-Requests arbeitet, die mMn ja sowieso in die Tonne gehören, aber immer gerne als "Best Practice" verkauft werden :-P
Es vereinfacht den Angriff vielmehr. Sobald ich als Angreifer eine Session-ID ergattert habe, erzeuge ich schnell viele Requests, sodass ich (aufgrund irgendeiner Heuristik) eine neue ID zugewiesen bekomme.
Das ist alles eine Frage von "wie schnell"?
Damit ist es dem tatsächlichen Nutzer nicht einmal mehr möglich auszuloggen.
Da ist ein Denkfehler im System. Der rechtmäßige Besitzer IST DANN "AUSGELOGGED".
Allerdings merkt er es üblicherweise nicht, wenn ein Trittbrettfahrer auf seiner Session mit konsistenter Session-ID herumreitet. Er merkt es aber sofort, wenn ein Trittbrettfahrer auf seiner Session mit wechselnder Session-ID herumreitet. Dann ist nämlich seine eigene Session-ID auf dem Client schon beim nächsten Request ungültig. Er wird sich damit vermutlich neu anmelden und damit kann dann der Dieb mit der von ihm ergatterten SID auch nix mehr anfangen.
Ich habe die Session komplett übernommen, kann sie am Leben erhalten und der Nutzer ist ausgesperrt.
Ausgesperrt ist vollkommen falsch! Siehe oben!
In eine Sessiondatei gehören allerdings keine Credentials!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Der Martin
Matthias Apsel