Ein Loginscript

[Felix Riesterer]

Lieber Christian,

Am besten speichert man nur das in der Session, was sich nicht umgehen lässt. Z.B. die ID des Users, der sich eingeloggt hat. Nicht aber das User-Objekt aus der Datenbank.

stellen wir uns das einmal vor: Der Account ist via Session-Hijacking kompromittiert. Der böse Hacker kann nun den Account nutzen, da er eine alte Session übernommen hat. Der eigentliche User hat sich neu angemeldet und eine neue Session begonnen. Nehmen wir an, dass der User nun das Passwort ändert. Würde der Session-Mechanismus das bei der Anmeldung eingegebene Passwort speichern und bei jedem Request gegen das in der DB prüfen, würde die Session des bösen Hackers plötzlich unbrauchbar, da in der übernommenen Session ein nicht mehr gültiges Passwort steht. Beim eigentlichen User wurde in der Session das geänderte Passwort natürlich eingetragen, damit seine Session weiter benutzbar bleibt, ohne dass eine indirekte Zwangsabmeldung erfolgt.

Nach meinem bescheidenen Wissensstand ist das nur dann möglich, wenn Du einem User mehrere Sessions erlaubst (also die Session nicht in einer DB speicherst) und wenn Du das bei der Anmeldung benutzte Passwort in der Session speicherst.

• Cookie mitschnüffeln über eine unverschlüsselte Verbindung. Da hilft das Vergeben einer neuen Session-ID gar nichts, denn ich bekomme ja auch immer die Antwort des Servers mit. Das einzige, was hier hilft, ist HTTPS; die Cookies sollten dann mit force SSL flag gesetzt werden.

OK. Das ist wahr.

• Die Leute sitzen an einem öffentlich zugänglichen Gerät und loggen sich nicht aus wenn sie gehen; hier hilft das vergeben einer neuen Session-ID gar nichts, denn der Angreifer ist ja am selben Rechner wie die Person zuvor. Hier hilft es nur, einen Logout-Button anzubieten, möglichst prominent.

Unachtsamkeit kann man technisch nicht oder nur sehr schlecht vorbeugen.

gängige Praxis: nach der Authentifizierung wird eine neue Session-ID generiert, so dass der Angreifer nicht mehr die alte Session-ID nutzen kann.

In dem Moment, wo Du dem User eine bestimmte Session-ID unterjubeln kannst, musst Du seinen Client oder dessen Verbindung zum Server ausreichend kompromittiert haben, sodass eine neue Session-ID auch keine Rolle mehr spielen sollte.

Entweder der User kommt mit einer gültigen Session-ID an, oder nicht. Sollten seine Session-Daten in Ordnung sein, ist er auch eingeloggt. Das kannst Du damit überprüfen, indem Du in den Session-Daten (aber nicht im Cookie und schon gar nicht in irgendeinem URL-Parameter!!) das Passwort des Users (gerne als Hash aus der DB) ablegst und bei einem Request gegen den Hash aus der DB abgleichst.

Welche zusätzliche Sicherheit bietet das? Entweder die Session ist im Cookie gespeichert, dann ist sie prinzipiell auch manipulierbar. Wenn nicht bei der User-ID, dann ggfls woanders. Hier nutzt man aus genau diesem Grund kryptografisch signierte Session-Daten.

Ich schreibe nichts in ein Cookie, sondern lasse PHP den Session-Namen (ist das etwas anderes als die Session-ID?) hineinschreiben, was PHP von selbst macht. Den Rest speichere ich in $_SESSION, was ich als "in der Session speichern" bezeichne. Das, was man in ein Cookie schreiben könnte, würde ich als "im Cookie speichern" nennen.

Oder die Session-Daten sind, wie z.B. bei PHP üblich, in der Datenbank oder in Session-Dateien gespeichert, dann kann die Session auch nicht manipuliert werden.

Letzteres war von vornherein mein Verständnis. Wie sollte man das sinnvoll anders machen? Die DB dafür bemühen hieße ja, dass ich Dinge neu implementiere, die mir PHP von selbst schon anbietet. Das vermeide ich gerne.

Eine „Absicherung“ über eine erneute Prüfung des Hashes ist nicht sinnvoll, denn es greift zu wenig weit im ersten Fall oder ist überflüssig im zweiten Fall.

Nicht dann, wenn ein User beliebig viele Sessions (z.b. in beliebig vielen Clients) starten kann und in einer davon das Passwort ändert und alle restlichen Sessions damit ihre Nutzbarkeit einbüßen sollen (s.o.).

Vielleicht hatte ich mich einfach ungünstig ausgedrückt?

Liebe Grüße,

Felix Riesterer.