DEMO sichere Session durch permanente Authentifizierung

Anstelle eines Session-Token tritt die Benutzerkennung

Bitte einloggen mit Benutzername und Passwort. Nach dem Einloggen sehen Sie die Zugriffe auf das Benutzerkonto.

Tokenbasierte Authentifizierung und XSRF (Cross-Site-Request-Forgery)

HTTP ist ein zustandsloses Protokoll. Den Zustand einer Anmeldung gibt es nicht in HTTP, auch dann nicht, wenn eine HTTP-Session aufgebaut wurde. Bestenfalls kann man den Zustand angemeldet zu sein, über eine Session emulieren! Der Ablauf ist so, daß nach einer erfolgreichen Authentifizierung in der Response ein Session-Cookie mit eine Token gesetzt wird. Im Weiteren erfahren wir, daß die Sicherheit einer Session gar nichts damit zu tun hat ob ein Passwort sicher oder unsicher ist.

Das Problem ist das Token (Session-ID). Bei jedem Folge-Request muß am Server nachgeschaut werden, ob das Token (was der Request mitsendet) erzeugt wurde, wann das Token erzeugt wurde und an welchen Benutzer es vergeben wurde. Dabei darf das Token nur einmal registriert sein. Das heißt, daß lediglich geprüft wird, ob die Session noch dieselbe ist. Auch wenn dieser Session ein Request einer Authentifizierung voraus gegangen ist, hat die Session selbst mit der Authenifizierung nichts mehr zu tun.

Egal über welchen Zeitraum: Ein Token muß atomar sein, es darf nicht vorkommen daß ein Token der zufällig erzeugt wurde mehreren Benutzern zugewiesen wird.

Bis dahin ist das vielleicht noch machbar. Aber stellen wir uns mal vor, Benutzer Alfred hat einen Token bekommen und darf Geld überweisen. Zufällig kommt in anderer Benutzer mit demselben Token und darf damit natürlich all das machen was Alfred gerade macht. Denn serverseitig wird ja nur das Token geprüft und davon ausgegangen daß der Benutzer der es bekommen hat Alfred ist. Das heißt, das auch die beste Sessionverwaltung de Welt nicht garantieren kann, daß ein Session-Token unteilbar ist. Ein solcher ist es erst dann, wenn er selbst die Authentifikation (Benutzername und Passwort) beinhaltet und überträgt.

Browsersitzungen (Sessions) werden i.d.R. über einen Cookie realisiert wobei dieser Cookie kein Ablaufdatum hat und infolgedessen mit dem Schließen des Browsers gelöscht wird. Üblicherweise wird dieser sog. Session-Cookie gesetzt nachdem sich der Benutzer ausgewiesen hat. Im Cookie selbst ist zum Namen der Session ein eindeutiger Schlüssel als Session-ID (Token) hinterlegt. Nachdem der Benutzer sich als berechtigt ausgewiesen hat, wird bei den nachfolgenden Requests nur geprüft ob die Session noch gültig ist und das ist der Fall wenn der Browser einen Cookie mit der gültigen Session-ID sendet, eine erneute Prüfung der Credentials (Benutzername, Passwort) findet hierbei nicht statt. Aus diesem Verhalten ergibt es sich, daß eine Session entführt werden kann, nämlich dann, wenn die Session-ID bekannt ist.

Ein weiteres Sicherheitsproblem ergibt sich daraus, daß sich unter zahlreich erzeugten Session-IDs beim serverseitigen Speichern eben auch zahlreiche Daten ansammeln die beim Schließen des Browsers leider nicht automatisch gelöscht werden sondern weiterhin persistent sind. Es ist zwar möglich, für die serverseitigen Daten ein Ablaufdatum zu definieren aber das löst das Problem nicht, daß auch unter dem Ablaufdatum zufällig eine Session mit derselben ID erzeugt werden kann womit der Anwender auf die privaten Daten Anderer Zugriff hat.

Die hier vorliegende Anwendung löst genau dieses Problem dadurch daß die serverseitig anfallenden Daten im Benutzerkonto gespeichert werden. Das erfordert, daß jeder Request die Credentials mitsenden muß damit sie serverseitig geprüft werden können. Anstelle also für jede neue Session ein neues Token zu erzeugen und bei jedem Request zu prüfen ob die Session noch gültig ist, werden nunmehr nur die Zugangsdaten bei jedem Request geprüft, also Benutzername und Passwort, was bei jedem Request gesendet wird. Auf diese Art und Weise hat nur derjenige Zugriff auf sein Benutzerkonto wenn er die richtigen Zugangsdaten eingegeben hat. Damit der Anwender seine Zugangsdaten nur einmal eingeben muß, gibt es auch hier einen Login-Prozess. Benutzername und Passwort als Crypt werden hierzu in einem Session-Cookie gespeichert. Sicherheitsbedenken dagegen gibt es keine, da ein Session-Cookie vom Browser nur solange im Speicher gehalten wird bis der Browser geschlossen wird.

Diese Anwendung löst das Cross-Site-Request-Forgery-Problem! Zeige Perlcode


Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. s​os­@rolf­rost.de.