Wenn Sie heute eine Website veröffentlichen, vergehen kaum ein paar Minuten, bis sie das erste Mal angegriffen werden. Diese Artikelserie beschäftigt sich mit den OWASP Top 10, den zehn meisten Sicherheitsrisiken, und gibt Tipps, wie sie sich und ihre Produkte schützen können.

Diese Serie besteht aus den folgenden Artikeln:

• Teil 1: Injection
• Teil 2: Fehler in Authentifizierung und Session-Management (dieser Artikel)
• Teil 3: Cross-Site Scripting (XSS)
• Teil 4: Unsichere direkte Objektreferenzen
• Teil 5: Sicherheitsrelevante Fehlkonfiguration
• Teil 6: Verlust der Vertraulichkeit sensibler Daten
• Teil 7: Fehlerhafte Autorisierung auf Anwendungsebene
• Teil 8: Cross-Site Request Forgery (CSRF)
• Teil 9: Nutzung von Komponenten mit bekannten Schwachstellen
• Teil 10: Ungeprüfte Um- und Weiterleitungen

Fehler in Authentifizierung und Session-Management

Auf Platz 2 der OWASP Top 10 sind Fehler in Authentifizierung und Session-Management. Wenn auch schwieriger als SQL Injection, sind solche Fehler doch einfach zu entdecken. Mit ein Grund, weshalb solche Fehler häufig auftreten, ist das mangelnde Know-how vieler Webentwickler.

OWASP stuft die Auswirkungen von Fehlern in Authentifizierung und Session-Management als schwer ein. Wenn es einem Angreifer gelingt, die Session eines privilegierten Benutzers zu stehlen, kann er sich als dieser ausgeben und grossen Schaden anrichten.

Eine Möglichkeit an die Session des Opfers zu gelangen, ist das Stehlen des Cookies. Ein Angreifer ist selten am Computer der Zielperson, dann wäre es sehr einfach. Meistens werden Cookies über einen XSS Angriff oder über eine unsichere HTTP Verbindung ausgelesen. In einem öffentlichen WLAN ist dieses Risiko beispielsweise sehr gross.

Eine andere Möglichkeit die Session eines Opfers zu stehlen geht über die URL. Manche Webseiten schreiben die Session ID in die URL anstatt in ein Cookie. Oftmals ist diese Vorgehensweise der Standard Fallback für Browser, die Cookies nicht unterstützen. Sobald die Session ID in der URL enthalten ist, ist es viel schwieriger, sie geheim zu halten. Ein Benutzer kann beispielsweise die URL auf Social Media veröffentlichen, weil er sich dessen Risiko nicht bewusst ist. Auch in öffentlichen Fehler-Logs können solche URLs auftauchen. Ein Angreifer hat so ein leichtes Spiel.

Es gibt aber noch andere Fehler in Authentifizierung und Session-Management. Eine korrekte Benutzerverwaltung gibt ihre Mitglieder nicht preis; es soll einem Angreifer also nicht möglich sein herauszufinden, ob ein bestimmter Benutzer existiert oder nicht. Es darf auch nicht möglich sein, über eine 'Passwort zurücksetzen' Funktion die Kontrolle über ein Konto zu erhalten, indem dort Fragen gestellt werden, die jedermann via Social Engineering herausfinden kann.

Dass Session IDs in URLs eine schlechte Idee sind, wissen Sie nun. Aber wie können Sie verhindern, dass ein Angreifer an das Cookie gelangt? Wenn der Server einem HTTP Response ein Cookie mitgibt, kann er das HTTP Only Flag setzen. Ist dieses Flag gesetzt, verhindert der Browser, dass JavaScript Code auf das Cookie zugreifen kann. Ein XSS Angriff führt somit nicht zum gewünschten Erfolg.

Damit das Cookie nicht wegen eines öffentlichen WLANs verloren geht, werden Sie natürlich HTTPS einsetzen. Geld ist hier ja kein Argument mehr, es gibt mehrere Anbieter von kostenlosen Zertifikaten. Ein Problem gibt es dann, wenn der Benutzer eine Seitenanfrage über HTTP absetzt. Normalerweise wird das Cookie in diesem Fall ebenfalls übermittelt, auch wenn es ursprünglich über HTTPS ausgestellt worden ist. Durch das Setzen des Secure Flags kann man das verhindern. Cookies, die das Secure Flag gesetzt haben, werden nur über eine abgesicherte Verbindung übermittelt.

Versuchen Sie zusätzlich, die Auswirkungen eines möglichen Cookie-Leaks zu minimieren. Das können Sie, indem Sie die Gültigkeitsdauer der Session limitieren. Ein sehr gutes Pattern ist auch, vor potentiell gefährlichen Aktionen das Passwort nochmals zu verlangen. Es soll einem Benutzer nicht möglich sein, das Passwort zu ändern, ohne das aktuelle Passwort einzugeben. Auch den Benutzernamen nicht. Weitere gefährliche Aktionen können das Löschen von bestimmten Daten sein oder das Tätigen einer Bestellung über einem bestimmten Warenwert. Selbst wenn der Angreifer an die Session seines Opfers gelangen konnte, kann er ohne das aktuelle Kennwort zu wissen, dieses nicht ändern.

Wie bereits angesprochen, gibt es noch weitere Fehler in Authentifizierung und Session-Management. Geben Sie bei einem missglückten Loginversuch die gleiche Fehlermeldung aus, unabhängig davon ob das Passwort falsch war oder der Benutzer gar nicht existiert. Das gleiche gilt für Funktionen wie Passwort vergessen und auch Registrieren. Ebenfalls ein grosser Fehler ist die Übertragung von Passwörtern per E-Mail. Implementieren Sie stattdessen einen sauberen, sicheren Passwort zurücksetzen Prozess.

Ermutigen Sie ihre Benutzer, starke Passwörter zu wählen. Das erreichen Sie durch eine Anzeige, die die Passwortstärke anzeigt. Auch eine Mindestlänge kann hier helfen. Verzichten Sie unbedingt auf weitere Restriktionen wie maximale Passwortlänge oder verbotene Sonderzeichen. Verzichten Sie auch darauf, einen Benutzer nach einer bestimmten Anzahl falscher Passworteingaben zu sperren. Ein Angreifer könnte das ansonsten bewusst ausnutzen, um das Opfer auszusperren. Eine temporäre Sperre von drei Minuten reicht vollkommen, um Brute Force Angriffe massiv zu erschweren.

Ist Ihre Anwendung sicher? Nebst der in diesem Blog beschriebenen Möglichkeiten gibt es viele weitere Strategien, sich gegen Angreifer zu verteidigen. Gerne beraten ich Sie in Sicherheitsfragen oder führe ein Security Review in Ihrem Projekt durch. Kontaktieren Sie mich unverbindlich, um Ihre dringlichsten Fragen zu besprechen.