Ein Loginscript

[Christian Kruse]

Hallo Felix,

Beim Login versuche ich 2 Cookies zu setzen. Ein SESSION-Cookie und einen normalen.

Was bitte ist ein "normales" Cookie? Zu Deiner Domain legt der Browser ein Cookie ab, in welches Du Daten schreiben lassen kannst. Es empfiehlt sich sehr, dass Da nur und ausschließlich die Session-ID steht. Alles andere speicherst Du in der Session.

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.

Wenn der User keine Cookies zulässt, dann brauchst Du einen URL-Parameter mit der Session-ID […]

Diese Technik ist veraltet und sollte nicht mehr verwendet werden, sie birgt zahlreiche Fallstricke. Der offensichtliche Grund ist, dass Links dann nicht mehr kopiert und an dritte weitergeschickt werden können. Wenn der User keine Cookies zulässt, sollte er keinen Zugriff bekommen.

was noch ein Grund mehr ist, überhaupt nur diese Information an den User auszugeben. Auch für diesen Fall bietet PHP diverse Voreinstellungen an, die Du nutzen (oder selbst implementieren) kannst.

Von der Verwendung von session.use_trans_sid wird abgeraten, sie vereinfacht session fixation stark.

// userid mit irgendwas multipliziert
$_SESSION['USER'] = '541 4a4350df2403b94a13304ee88b861041';
$_COOKIE['USER']  = '541 4a4350df2403b94a13304ee88b861041';

Das bedeutet, dass die Passwort-Informationen im Cookie des Users auf dessen Computer abgelegt werden. Das willst Du nicht, da bin ich mir sicher, […]

Urgh, ja, das will man definitiv nicht.

// Wenn Session, aber kein Cookie, Loginformular - damit ist schonmal Session Hijacking unterbunden
if $_SESSION['USER'] AND !$_COOKIE['USER']
  exit()

Ein Session-Hijacking unterbindest Du sinnvollerweise dadurch, dass Du bei jedem Request eine neue Session-ID generieren lässt.

Diese Aussage halte ich nicht für haltbar.

Schauen wir uns mal an, welche Angriffsvektoren es für Session Hijacking gibt:

• 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.
• 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.
• Der Cookie wird über XSS erschnüffelt. Hier hilft es am ehesten, den Cookie JS nicht zugänglich zu machen. secure, wie oben schon erwähnt, und httponly sollten in jedem Fall gesetzt werden.
• Session Fixation. Der Angreifer erstellt sich ein valides Session-Token (z.B. indem er die Login-Seite besucht) und schiebt dieses Token dem User unter, z.B. über XSS. Der wiederum loggt sich mit diesem Session-Token ein. Hier hilft es tatsächlich, eine neue Session-ID zu erstellen, das ist auch gängige Praxis: nach der Authentifizierung wird eine neue Session-ID generiert, so dass der Angreifer nicht mehr die alte Session-ID nutzen kann.

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.

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.

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.

Ich könnte das ganze jetzt um eine weitere Prüfung erweitern, in dem ich einfach alle vom User genutzten IPs beim Login checke, ob die aktuell nur mit Cookie aufrufende IP schon einmal genutzt wurde, wenn nicht, Login erzwingen. Ohne diese Prüfung könnte ein Hacker, wenn er die Userid und das gehashte Passwort richtig errät, das Profil kapern. Was aber ja auch schon schwierig genug sein dürfte.

Warum? Du hast bei manchen Providern den Fall, dass Leute bei einem Seitenaufruf die einzelnen Dateien mit unterschiedlichen IP-Adressen aufrufen, da der Provider die Requests über einen Pool an IP-Adressen leitet. Das würde die User-Experience im Zweifelsfall empfindlich behindern!

Das ist zwar prinzipiell richtig, aber fehlendes Rate Limiting ermöglicht auch einen Brute-Force-Angriff. Deshalb ist es heutzutage eher üblich, den Zugriff durchaus zu beschränken. Welches Kriterium dort herangezogen wird ist allerdings unterschiedlich; häufig wird trotzdem die IP benutzt, manche nutzen eine Session-ID, manche andere Kriterien.

LG,
CK