Du hast deine E-Commerce-, Digitalisierungs- und OPENAI-Experten gefunden.
Den meisten Benutzern ist kaum klar, auf was für einem unsicheren Fundament eigentlich die ganze Sicherheit im Web besteht. Das grundsätzliche Problem entsteht durch den “Stateless”-Ansatz im verwendeten Protokoll: Was für Webapplikationen vieles vereinfacht, ist eigentlich (wie so oft) ein Murks aus Security-Sicht.
Während bei HTTPS der Client immerhin (einigermassen, Stichwort man-in-the-middle) sicher sein kann, mit dem richtigen Server zu sprechen, ist das umgekehrt viel unsicherer: Woher weiss der Server, dass er mit dem “echten” Admin oder dem “richtigen” Bankkunden spricht? Der Client hat kein Zertifikat, das ihn ausweist (die bestehenden Ansätze von TLS-Client-Zertifikaten sind leider vom Handling her nahezu unbrauchbar, daher werden sie auch nicht implementiert).
Es gibt sie, die sinnvollen Konzepte für (endlich) mehr Sicherheit im Web.
Daher schickt der Server dem Client nach erfolgter Authentifizierung in den meisten Fällen ein Session-Cookie. Dieses schickt der Client bei jedem neuen Request mit, und das muss dem Server reichen, um darüber zu entscheiden, ob dies nun wirklich der angemeldete Admin oder Bankkunde von grad vorher war.
Das Problem:
So ein Cookie ist per se eine ziemlich unsichere Sache, ist weder verschlüsselt noch sonstwie gesichert. Zwar wird die Datenübermittlung (hoffentlich) per HTTPS gesichert, aber da der Browser selber das Cookie auslesen kann (sprich jedes Skript der Website), ist das schon eine sehr unsichere Sache: Gelingt es einem Angreifer, ein paar Zeilen JavaScript-Code in die Website einzuschleusen, ist das Cookie geklaut, dem Angreifer geschickt, welcher sich nun bequem als ebendieser bereits authentifizierte Admin oder Bankkunde ausgeben und unter seinem Namen weiter surfen kann (Session Hijacking).
Eigentlich ist das richtiggehend eine Dummheit: Warum sollte der Website-Inhalt in der Lage sein, die Sicherheit derart zu unterwandern? Eigentlich sollte der Inhalt der Website überhaupt keinen Zugriff auf die Sicherheitsmerkmale haben. Da aber HTTP eben “stateless” ist, Sicherheit aber doch einen State erfordert (bin ich angemeldet und zugriffsberechtigt?), wird dieser notgedrungen auf Applikationsebene implementiert – wo er eigentlich nicht hin gehört.
Auf BrowserAuth.net wird eine sehr elegante und eigentlich recht einfache Lösung vorgeschlagen. Wenn
hätten wir mit wenig Aufwand sehr viel erreicht – CSRF und damit Session Hijacking, die aufgrund ihrer Einfachheit wohl gefährlichsten und am weitesten verbreiteten Angriffsformen, wären massiv erschwert. Der Admin sowie der Bankkunde könnten viel ruhiger ihrer Arbeit nachkommen.
Abbildung: Mehr Sicherheit: An das Browserzertifikat gebundenes Session-Cookie
Dass der Vorschlag von Dirk Balfanz, welcher dem Google Security Team angehört, lässt hoffen, dass hier mit Nachdruck daran gewirkt wird. Wir sind auf jeden Fall gespannt, wie’s weiter geht.
Du hast deine E-Commerce-, Digitalisierungs- und OPENAI-Experten gefunden.
