Ein Loginscript

[Christian Kruse]

Hallo Felix,

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.

Ich wollte hier darauf hinaus, dass man sparsam mit der Session umgeht. Man handelt sich sonst allerlei Probleme ein, z.B. Synchronisations-Probleme.

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.

Das Beispiel halte ich für reichlich konstruiert. Viel Wahrscheinlicher ist es, dass der User das gar nicht mitbekommt. Und dass er just in diesem Augenblick zufällig sein Passwort ändert ist unrealistisch und nichts, worauf ich mich verlassen wollen würde.

Und umgekehrt, mit den neuen Hashing-Verfahren, spätestens jedoch mit Argon2 ist das verifizieren des Passworts richtig teuer.

Man kauft sich also einen zweifelhaften Sicherheitsgewinn mit viel CPU-Zeit.

Wollte man diesen Fall allerdings abdecken, dann wäre das ein gangbarer Weg, ja.

• 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.

Exakt darauf wollte ich hinaus ;-)

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.

Das ist nicht richtig. Übliches Szenario für eine Session Fixation ist eine XSS-Lücke, z.B. so:

document.cookie = 'PHPSESSIONID=blub';

Eine neue Session-ID, gerade wenn sie mit httponly und secure gesetzt wurde, wird allerdings auf Client-Seite nicht auftauchen.

Ich glaube, du denkst noch nicht verwunden genug ;-)

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.

Die Definition ist irreführend. Es gibt die Session (als abstrakten Begriff), in der man Werte speichern kann. Wo die Session gespeichert wird ist davon unabhängig; der session storage kann ein Cookie sein, so dass die Session auf den Server gar nicht existiert sondern nur auf dem Client. Es kann eine Datei sein, oder es kann die Datenbank sein. Üblich ist bei PHP eine Session-Datei, es geht jedoch auch bei PHP auch anders.

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?

Bei Rails wird die Session per Default im Cookie gespeichert (und signiert sowie verschlüsselt, bevor sie an den User gesendet wird); das geht auch mit PHP, siehe mein Link von oben.

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.

Nein, das heisst nur, dass du ein paar Methoden implementieren musst ;)

LG,
CK