Dieser Beitrag unserer Reihe zur OWASP Top Ten, den häufigsten Sicherheitslücken in Webapplikationen, beschäftigt sich mit Fehlern in der Authentifizierung und dem Session-Management.

Webapplikationen, die benutzerbezogene Dienste anbieten (z.B. Social-Media-Webseiten) sind darauf angewiesen, dass sich der Benutzer gegenüber der Webapplikation authentifiziert. Dies geschieht in den meisten Fällen per Benutzername und Passwort.

Hat sich der Benutzer einmal authentifiziert, sorgt das Session-Management dafür, dass die weitere Kommunikation mit der Webapplikation als angemeldeter Benutzer stattfindet. Dies geschieht meist über Session-IDs in der Form von Cookies, also im Browser gespeicherte Informationen, die zur Authentifizierung gegenüber der Webapplikation gespeichert werden. Dies hat den technischen Hintergrund, dass das http-Protokoll, über das Browser mit einem Webserver kommunizieren, zustandslos ist. Daher sind alle Seitenaufrufe für den Server unabhängig voneinander und stehen in keinem Zusammenhang. Mithilfe von Cookies wird  der Webapplikation deshalb über mehrere Anfragen hinweg im gesamten Zeitraum der Anwendungssession vermittelt, dass man noch derselbe Benutzer ist. Als Session-ID wird typischerweise eine lange, zufällige Zeichenkette verwendet, wie z.B. b857bbd11d7d8c94f84959d1a36900ed4ca706df. Dadurch soll sichergestellt werden, dass Session-IDs eindeutig sind und nicht leicht erraten werden können.

Fehlerhaft programmierte Authentifizierungs- oder Session-Management-Mechanismen können zur Kompromittierung oder Übernahme von Benutzerkonten führen. Im Rahmen eines Webapplikationstests kommt der Überprüfung dieser Bereiche daher große Bedeutung zu.

Fehlerhafte Authentifizierung

Es gibt mehrere Möglichkeiten für fehlerhafte Authentifizierungsmechanismen:

  • Benutzernamen und Passwörter können leicht durch das systematische Ausprobieren aller möglichen Kombinationen (Brute-Force-Angriff) erraten werden.
  • Die Webapplikation gibt aussagekräftige Rückmeldungen über bereits bestehende Benutzernamen (z.B. über Passwort-Zurücksetzen-Funktionen oder bei der Kontenerstellung) und erleichtert somit Wörterbuch- oder Brute-Force-Angriffe.
  • Benutzernamen oder Passwörter anderer Benutzer lassen sich durch fehlerhafte Überprüfungen der horizontalen Zugriffsberechtigungen manipulieren.
  • Passwörter werden nicht geschützt gespeichert (ohne Hashverfahren oder Verschlüsselung), wodurch sie sich über eine andere Sicherheitslücken (z.B. mittels SQL-Injections) auslesen lassen.
  • Benutzername und Passwort werden bei der Anmeldung im Klartext und nicht verschlüsselt über https übertragen. Dadurch kann ein Angreifer die Kommunikation abhören und so an gültige Anmeldedaten gelangen.

Fehlerhaftes Session-Management

Auch im Session-Management gibt es verschiedene Arten von Sicherheitslücken:

  • Session-IDs sind nicht ausreichend zufällig gewählt, weshalb sich gültige Session-IDs leicht erraten lassen.
  • Session-IDs behalten auch nach dem Abmelden des Benutzers ihre Gültigkeit und können genutzt werden, um die Anwendersession wiederherzustellen.
  • Session-IDs werden nicht in Form von Cookies, sondern als Parameter in der URL übertragen. Sofern eine URL mit Session-ID in falsche Hände gelangt(z.B. als Link per E-Mail oder aus dem Browserverlauf), ermöglicht sie die Session-Übernahme und damit die Verwendung aller Funktionen der Webapplikation mit den Rechten des angemeldeten Benutzers.
  • Session-IDs ändern sich nicht mit erneuter Anmeldung und sind daher ebenfalls leicht vorhersagbar.
  • Session-IDs werden im Klartext übertragen, statt verschlüsselt über https. Dadurch kann ein Angreifer die Kommunikation abhören und mit einer gültigen Session-ID die Sitzung des gerade angemeldeten Benutzers übernehmen.
  • Aufgrund des nicht gesetzten HttpOnly-Attributs kann der Session-Cookie über Skriptsprachen, beispielweise mittels JavaScript, ausgelesen werden, um somit z.B. im Rahmen eines Cross-Site-Scripting-Angriffs (XSS) die Session-ID eines anderen Nutzers zu bestimmen.

Gegenmaßnahmen

Um die beschriebenen Angriffsszenarien zu vermeiden, sollten die Authentifizierungsfunktionen zunächst so gestaltet sein, dass nach mehrmaliger Fehleingabe der Anmeldedaten das entsprechende Benutzerkonto und/oder die Aufrufer-IP temporär gesperrt werden. Zudem sollten weder bei der Registrierung noch bei einer Passwort-Vergessen-Funktion aussagekräftige Rückmeldungen über bereits existierende Benutzernamen ausgegeben werden. Sofern dies aus Gründen der Benutzerfreundlichkeit nicht möglich ist, können zumindest automatisierte Abfragen mittels eines sogenannten CAPTCHAs unterbunden werden. Zusätzlich sollten Anmeldedaten ausschließlich verschlüsselt mittels TLS übermittelt und Passwörter in gehashter Form mit geeigneten kryptografischen Funktionen gespeichert werden. Für sichere Passwort-Hash-Funktionen bieten sich PBKDF2 oder bcrypt an.

Session-IDs sollten ausreichend zufällig gewählt, nicht unverschlüsselt übertragen und bei einer Abmeldung serverseitig terminiert werden. Um eine verschlüsselte Übertragung der Session-ID zu erzwingen, kann zusätzlich das Secure-Attribut des Session-Cookies aktiviert werden. Neben dem Secure-Attribut sollte außerdem das HttpOnly-Attribut gesetzt werden, um ein Auslesen des Cookies mittels JavaScript zu verhindern. Zur Vermeidung von Session-Übernahmen kann weiterhin die Session eines Anwenders mit spezifischen Nutzermerkmalen, wie z.B. dem entsprechenden User-Agent oder der IP-Adresse verknüpft werden.

Neben diesen Standardmaßnahmen sollten weiterhin die von der OWASP formulierten Anforderungen an Authentifizierung und Session-Management umgesetzt werden. Diese sind in den OWASP Application Security Verification Standards beschrieben.

Zusammenfassung

Authentifizierung und Session-Management sind komplexe Mechanismen, bei denen leicht Fehler und Sicherheitslücken auftreten können. Die Folgen sind die Kompromittierung sowie die Übernahme von Benutzerkonten. Je nach Funktion der Webapplikation kann ein solcher Identitätsmissbrauch schwere, z.T. finanzielle Folgen für die Benutzer, und dadurch auch den Anbieter der Applikation haben.

Der vorige Teil dieser Reihe zur OWASP Top Ten, den häufigsten Webapplikationsschwachstellen behandelte A1: Injections. Der nächste Teil beschäftigt sich mit Punkt A3: Cross-Site Scripting.