Vorsicht beim Setzen des Ablaufdatums einer Session

Session Cookies werden nach wie vor häufig verwendet um einen Benutzer während der Nutzung einer Website oder (Web-)App angemeldet zu lassen und die lästige erneute Eingabe des Passwortes zu vermeiden. Oft werden dabei Ablaufdaten für die Sessions gesetzt, sodass die Cookies nach einiger Zeit automatisch gelöscht werden um einen langfristigen Missbrauch zu verhindern. Aber hinter genau diesem Ablaufdatum versteckt sich eine mögliche Sicherheitslücke, je nachdem wie es eingesetzt wird.

In diesem Artikel zeige ich euch zwei Beispiele in zwei Technologien, wo ein falsch benutztes Ablaufdatum dazu führen kann, dass ein Benutzer weiterhin ungewollten Zugriff auf eine Seite erhält. Und was wäre ein Dev-Blog Beitrag ohne ein nur halb gut passendes Stock Photo am Anfang, also:

Vorwort

Ein Ablaufdatum für einen Session Cookie festzulegen ist relativ einfach. Der Cookie hat dazu ein beschreibbares expires Feld. Diesen Wert kann man in der Entwicklerkonsole eines beliebigen Browsers einsehen und auch verändern.

Der Browser entscheidet dann anhand dieses Wertes ab wann der Cookie verworfen wird. Steht hier einfach „Session“ wird der Browser den Cookie entfernen sobald er geschlossen wird. Wenn man den Browser neu öffnet muss man sich also auf der entsprechenden Seite neu einloggen. Steht hier ein Datum, wird der Browser den Cookie zu diesem Zeitpunkt verwerfen.

Die Gefahr besteht aber darin sich naiv darauf zu verlassen, dass der Cookie zu diesem Zeitpunkt nicht mehr existiert. Denn wie bereits erwähnt: Man kann diesen Wert einfach in der Entwicklerkonsole jedes Browsers verändern. Entwickler müssen also darauf achten, dass dieses Ablaufdatum auch Serverseitig geprüft wird. Andernfalls kann jemand sich dauerhaft Zugriff auf eine Webseite oder (Web-)App verschaffen, selbst wenn die Person den Zugang schon längst hätte verlieren sollen.

Die Umsetzung dabei hängt von der genutzten Technologie ab. Eine Möglichkeit wäre es zum Beispiel das Ablaufdatum der Session auch Serverseitig zu speichern. Eine weitere Möglichkeit wäre es das Datum in den Hash des Cookies einzufügen, der für die Authentifikation genutzt wird. Der Server muss dann zudem erwarten, dass der Client zusätzlich das Ablaufdatum des Cookies sendet. Somit kann der Server den Hash dann bei eingehender Anfrage erneut bauen und mit dem überlieferten vergleichen. 

Wie auch immer, es geht hier nicht um die Implementierungs-Details. Ich wollte mit diesem Beitrag nur darauf aufmerksam machen, dass einige Technologien diese Serverseitige Überprüfung nicht mitliefern. Man sollte das als Entwickler immer überprüfen. Hier zwei Beispiele:

Ruby On Rails

In Ruby on Rails kann man im Session Store den Wert expire_after setzen um ein Ablaufdatum für Sessions festzulegen. In einem Initializer muss dann folgendes aufgerufen werden:

Rails.application.config.session_store :cookie_store, expire_after: 14.days

(Quelle: Rails Dokumentation)

In diesem Fall wird Rails mit jedem Request das Ablaufdatum der Session Serverseitig prüfen. So weit, so gut.

In Rails ist es aber auch möglich Werte des Cookies in der Controller- Action direkt zu setzen. Dazu hat man ein session objekt, welches man nach belieben ergänzen kann. In diversen Internetquellen findet man deswegen auch oft den Lösungsvorschlag dieses session Objekt zu verwenden, um das Ablaufdatum zu setzen, wie zum Beispiel in diesem Stack Overflow Beitrag.

Das würde dann so aussehen:

session[:expires_at] = 60.minutes.from_now

Aber Vorsicht, hier verbirgt sich eine Falle. Wenn man nicht die zuvor erwähnte Einstellung über den Session Store verwendet und das Ablaufdatum einfach über das Session Objekt festlegt, wird Rails zwar das Datum in das Session Cookie schreiben, sodas der Browser den Cookie auch maximal bis zum Ablaufdatum behält, aber Rails prüft das Ablaufdatum nicht Serverseitig. Deshalb kann man in diesem Fall das Datum in der Entwicklerkonsole des Browsers einfach manipulieren und bleibt angemeldet.

WordPress

WordPress ist eines der weit verbreitetsten CMS. Dennoch überprüft WordPress das Ablaufdatum der Session nicht Serverseitig...

Es ohne weiteres Möglich das Ablaufdatum in den Browsereinstellungen zu ändern. In meinem Beispiel benutze ich ein Wordpress der Version 6.4.2. Wenn man sich in einem Wordpress Backend angemeldet hat, erscheinen unter Anderem die folgenden Cookies:

Für die Cookies ist das Ablaufdatum Session festgelegt, wodurch der Cookie nach Schließen des Browsers entfernt werden sollte. So weit, so gut.

Wenn man dies aber umgeht und das Ablaufdatum in der Entwicklerkonsole eines beliebigen Browsers ändert, bleibt der Cookie über die Session hinweg bestehen.

Jetzt können wir den Browser schließen und nach Neustart müssen wir nicht erneut das Passwort eingeben. Auf diese weise kann man dauerhaft eingeloggt bleiben. WordPress überprüft also das Ablaufdatum nicht Serverseitig. Das kann insbesondere dann ein Risiko sein, wenn der Arbeitsrechner von mehreren Personen genutzt wird.

Fazit

Ablaufdaten von Cookies zu setzen ist eine gute Sache und sorgt dafür, dass Benutzer sich zwar nicht ständig neu einloggen müssen, aber auch die Sicherheit haben dass bei einer vergessenen Session eines Browsers diese nicht für immer gültig ist. Entwickler sollten aber darauf achten, dass die Ablaufdaten auch Serverseitig überprüft werden. Man sollte bei jeder Technologie überprüfen, ob man das Ablaufdatum im Browser einfach ändern kann um eingeloggt zu bleiben. Ist dies der Fall, sollte man das den entsprechenden Technologien im besten Fall über eine Github Issue mitteilen.

Zum Schluss noch ein kleiner Wink mit dem Zaunpfahl: WordPress hat die Issues in den Github Repositories deakiviert, sodass ich diese Lücke nicht melden konnte. Wieso das so ist, das kann ja jeder für sich selbst entscheiden…

Ergänzung

Auch Amazon Workmail scheint keine Serverseitige Überprüfung des Ablaufdatums zu haben. Hier kann man auch einfach das Datum von "Session" auf ein beliebiges Datum setzen und man bleibt eingeloggt. Das ist insbesondere für geteilte Arbeitsplätze interessant... Dabei bemerkt man, dass selbst einer der größten Anbieter für Cloud Services auch nur mit Wasser kocht ;).