Samstag, 13. August 2011


Topthema

Donnerstag, 14. Januar 2010 | Topthema

About Security #238: Schwachstellen-Suche: Sichere Authentifizierung (7)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/053347)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Eine Sicherheitsfrage vor der Funktion zum Zurücksetzen des Passworts führt möglicherweise zur Preisgabe gültiger Benutzernamen. Die kann der Angreifer gut für weitere Angriffe auf die Authentifizierung gebrauchen.

Frage da, Benutzername gültig

Können die Benutzer die Sicherheitsfrage selbst wählen, werden gültige Benutzernamen allein schon am Vorhandensein der Frage erkannt: Gibt es eine Sicherheitsfrage, existiert der entsprechende Benutzername, gibt es keine, existiert auch der Benutzername nicht. Daher dürfen nur von der Webanwendung vorgegebene Fragen verwendet werden, deren Antworten dann aber nicht zu leicht zu erraten sein dürfen. Denn ein Angreifer kann gültige Benutzernamen auf jedem Fall daran erkennen, dass er nach dem Raten der richtigen Antwort Zugriff auf die Funktion zum Zurücksetzen des Passworts hat. Außerdem muss darauf geachtet werden, dass nicht durch die Fehlermeldungen verraten wird, ob der Benutzername existiert oder nicht: Sowohl beim Aufruf mit einem nicht existierenden Benutzernamen als auch beim Aufruf mit einem existierenden Benutzernamen, aber falscher Frage und/oder Antwort muss die gleiche Fehlermeldung ausgegeben werden.

Als Schutz vor Brute-Force-Angriffen sollte nach einer bestimmten Anzahl von Fehlversuchen der Zugriff auf die Funktion zum Zurücksetzen des Passworts für den betreffenden Benutzernamen für einige Zeit gesperrt werden.

Überwachung tut not

Alle zum Bereich der Authentifizierung gehörenden Funktionen müssen von der Webanwendung überwacht und verdächtige Vorfälle an die Administratoren gemeldet werden. Das betrifft z.B. das Ein- und Ausloggen, Passwortänderungen und -resets sowie das Löschen und Stilllegen von Benutzerkonten. Dabei sollten sowohl fehlgeschlagene als auch erfolgreiche Aufrufe protokolliert werden. Bei der Protokollierung müssen die relevanten Informationen wie z.B. der Benutzername und die IP-Adresse erfasst werden, während der geheime Teil der Zugangsdaten wie z.B. die Passwörter und die Antwort auf die Sicherheitsfrage gerade nicht protokolliert werden dürfen. Auf jeden Fall müssen die Logfiles besonders gut geschützt werden, da sie viele für einen Angreifer interessante Informationen enthalten.

Die Überwachung sollte möglichst in Echtzeit erfolgen, damit bei einem erkannten (möglichen) Angriff ggf. Intrusion-Prevention-Funktionen aktiviert sowie die Administratoren informiert werden können. Das gilt insbesondere bei der Erkennung von Brute-Force-Angriffen: Je weniger Zeit der Angreifer hat, desto geringer sind seine Erfolgsaussichten. Aber auch andere Anomalien können eine genauere Untersuchung durch die Administratoren erfordern, z.B. viele erfolgreiche Anmeldeversuche zu ungewöhnlichen Zeiten und/oder von unüblichen IP-Adressbereichen aus. Melden sich z.B. die meisten Benutzer von europäischen IP-Adressen aus an, wären viele erfolgreiche Anmeldungen mit z.B. südamerikanischen IP-Adressen erst einmal verdächtig. Das könnte darauf hindeuten, dass Phisher erfolgreich Zugangsdaten abgephisht haben - genauso gut könnten aber auch einfach einige Benutzer verreist sein und von unterwegs auf die Anwendung zugreifen.

Die Benutzer sollten über sicherheitsrelevante Vorgänge wie z.B. Passwortänderungen "out of band", i.a. also über E-Mail, informiert werden. Außerdem können sie innerhalb der Webanwendung bei jeder Anmeldung über den Zeitpunkt der letzten Anmeldung sowie über seitdem stattgefundene fehlgeschlagene Anmeldeversuche informiert werden. Fällt ihnen etwas Verdächtiges auf, informieren sie vielleicht die Betreiber der Webanwendung darüber.

Sorgfalt, Sorgfalt, Sorgfalt!

Die Authentifizierungsfunktionen sind die prominentesten Angriffsziele: Die meisten können naturbedingt von jedem Benutzer und damit auch Angreifer ungehindert erreicht werden, und nach einem erfolgreichen Angriff öffnen sie dem Angreifer dem Weg zum Rest der Anwendung. Dabei bieten sie sehr viele Möglichkeiten, beim Design oder bei der Implementierung Fehler zu machen, die später einen Angriff erlauben. Daher ist bei allem, was mit der Authentifizierung zu tun hat, besondere Sorgfalt nötig, und das gleich mehrmals: Alle Funktionen müssen sorgfältig entworfen werden, der Entwurf muss sorgfältig implementiert werden, die Implementierung muss sorgfältig auf Schwachstellen untersucht werden. Und damit nicht genug: Bei jeder Änderung müssen diese Schritte wiederholt werden. Ansonsten besteht die Gefahr, dass eine nachträglich eingeführte Funktion oder Option eine zuvor sichere Funktion unsicher oder gar unwirksam macht. Außerdem muss darauf geachtet werden, wirklich jede Funktion, die irgend etwas mit der Authentifizierung zu tun hat, zu berücksichtigen. Das sind nicht nur die Funktionen, die direkt etwas mit den Zugangsdaten zu tun haben wie die Funktionen zum Ein- und Ausloggen, zum Anlegen neuer Benutzerkonten und zum Ändern und Zurücksetzen des Passworts, sondern auch z.B. die Funktionen zum Wiedererkennen des Benutzers ("Remember me", siehe About Security #224) und zum Annehmen einer anderen Benutzeridentität ("User Impersonation", siehe About Security #225).

Hiermit ist die Entwicklung sicherer Authentifizierungsfunktionen abgeschlossen. In der nächsten Folge geht es wieder um die konkrete Suche nach Schwachstellen in Webanwendungen, und zwar um die nach Denial-of-Service-Schwachstellen.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren