alinnert
Mitglied
Ich mach mir schon eine ganze Zeit lang Gedanken darüber, wie man eine simple Benutzername-Passwort-gestützte Authentifizierung für http-APIs umsetzt. Ich hab dabei gerade einen Gedankengang, bei dem ich mir aber nicht 100%ig sicher bin, ob es da sicherheitstechnische Probleme gibt. Mein Gedankengang ist folgender:
Bei einem erfolgreichen Login würde ich ein httpOnly-Cookie mit einer ID setzen. Datenbankseitig stell ich eine Verbindung zwischen der ID und dem Nutzer her. So weiß ich beim Auslesen des Cookies über die Datenbank, welcher Nutzer den Request abgesetzt hat. Beim Ausloggen wird das Cookie gelöscht. Das Cookie-TTL beschränkt die maximale Login-Dauer (führt ggf. zu automatischem Logout). Die ID-Benutzer-Verbindungen müssen dann natürlich immer wieder gesäubert werden, damit keine Datensatzleichen entstehen.
Ich bin es nur gewohnt, dass man für Logins in PHP beispielsweise immer PHP-Sessions verwendet. Für so ziemlich jedes Framework gibt es auch spezielle Session-Middlewares. Bei meinem Gedankengang verwende ich aber keine Session im klassischen Sinne. Es ist viel mehr eine selbst implementierte Mini-Session.
Dadurch frag ich mich jetzt primär: Machen die Session-Libraries/-Middlewares etc. irgendwas großartiges, um die Sicherheit einer Anwendung zu erhöhen? Überseh' ich da irgendwas? Oder ist der einzige Mehrwert, dass man zusätzliche temporäre Daten für eine Session speichern kann? Dafür hätte ich bei meinem Projekt nämlich keinen Verwendungszweck. Wenn ich mir das sparen und stattdessen direkt mit dem Cookie interagieren kann, spar ich mir den Ärger mit den Session-Libraries, da sie dann nur Overhead sind.
Edit ‒ Hintergrund der Frage
Ich hab vergleichsweise große Probleme mit den Session-Implementierungen. Entweder sie funktionieren bei meinen Tests nicht (Go, Gorilla Session Package), oder es gibt keinen einfachen Store für kleinere Anwendungen, der anständig weiterentwickelt wird (SQLite, JSON-File..., ich möchte auf eine externe Datenbank verzichten) oder die Doku zum Implementieren eines eigenen Stores ist unvollständig, sodass ich nicht weiß, wie eine Implementierung überhaupt aussieht. Im Falle von Node.js braucht es auch eine funktionierende Type-Definition, da ich mit TypeScript arbeiten möchte.
Das hat mich alles so sehr frustriert, dass ich meine Anforderungen analysiert und aufs Notwendigste runtergebrochen hab. Dabei kam ich dann auf den Trichter: Alles, was ich brauche ist eine ID in einem Cookie und eine Verbindung zwischen den IDs und Benutzerkonten. Den Session-Store, also Session-Variablen, brauch ich gar nicht. Das klingt halt erstmal super simpel. Aber bevor ich das implementiere, möchte ich herausfinden, ob das sicherheitstechnisch überhaupt sinnvoll ist, oder ob ich mir das zu einfach vorstelle.
Bei einem erfolgreichen Login würde ich ein httpOnly-Cookie mit einer ID setzen. Datenbankseitig stell ich eine Verbindung zwischen der ID und dem Nutzer her. So weiß ich beim Auslesen des Cookies über die Datenbank, welcher Nutzer den Request abgesetzt hat. Beim Ausloggen wird das Cookie gelöscht. Das Cookie-TTL beschränkt die maximale Login-Dauer (führt ggf. zu automatischem Logout). Die ID-Benutzer-Verbindungen müssen dann natürlich immer wieder gesäubert werden, damit keine Datensatzleichen entstehen.
Ich bin es nur gewohnt, dass man für Logins in PHP beispielsweise immer PHP-Sessions verwendet. Für so ziemlich jedes Framework gibt es auch spezielle Session-Middlewares. Bei meinem Gedankengang verwende ich aber keine Session im klassischen Sinne. Es ist viel mehr eine selbst implementierte Mini-Session.
Dadurch frag ich mich jetzt primär: Machen die Session-Libraries/-Middlewares etc. irgendwas großartiges, um die Sicherheit einer Anwendung zu erhöhen? Überseh' ich da irgendwas? Oder ist der einzige Mehrwert, dass man zusätzliche temporäre Daten für eine Session speichern kann? Dafür hätte ich bei meinem Projekt nämlich keinen Verwendungszweck. Wenn ich mir das sparen und stattdessen direkt mit dem Cookie interagieren kann, spar ich mir den Ärger mit den Session-Libraries, da sie dann nur Overhead sind.
Edit ‒ Hintergrund der Frage
Ich hab vergleichsweise große Probleme mit den Session-Implementierungen. Entweder sie funktionieren bei meinen Tests nicht (Go, Gorilla Session Package), oder es gibt keinen einfachen Store für kleinere Anwendungen, der anständig weiterentwickelt wird (SQLite, JSON-File..., ich möchte auf eine externe Datenbank verzichten) oder die Doku zum Implementieren eines eigenen Stores ist unvollständig, sodass ich nicht weiß, wie eine Implementierung überhaupt aussieht. Im Falle von Node.js braucht es auch eine funktionierende Type-Definition, da ich mit TypeScript arbeiten möchte.
Das hat mich alles so sehr frustriert, dass ich meine Anforderungen analysiert und aufs Notwendigste runtergebrochen hab. Dabei kam ich dann auf den Trichter: Alles, was ich brauche ist eine ID in einem Cookie und eine Verbindung zwischen den IDs und Benutzerkonten. Den Session-Store, also Session-Variablen, brauch ich gar nicht. Das klingt halt erstmal super simpel. Aber bevor ich das implementiere, möchte ich herausfinden, ob das sicherheitstechnisch überhaupt sinnvoll ist, oder ob ich mir das zu einfach vorstelle.
Zuletzt bearbeitet: