Sonntag, 15. August 2010


Topthema

Donnerstag, 10. Dezember 2009 | Topthema

About Security #234: Schwachstellen-Suche: Sichere Authentifizierung (3)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/052896)

Die Entwicklung sicherer Authentifizierungssysteme bzw. die Behebung gefundener Schwachstellen ist auch das Thema dieser Folge. Zur bereits in About Security #233 behandelten korrekten Prüfung der Zugangsdaten gehört auch die richtige Reaktion auf Fehler bzw. mögliche Angriffe.

Die Anwendung sollte auf alle unerwarteten Eingaben oder Ereignisse während der Authentifizierung sehr restriktiv reagieren. Wenn ein Fehler auftritt, müssen sämtliche zur aktuellen Session und dem aktuellen Authentifizierungsvorgang gehörenden Informationen gelöscht und die Session explizit beendet werden, so dass ein Angreifer, der die Authentifizierung evtl. erfolgreich umgangen hat, zwangsweise ausgeloggt wird. Danach muss die Authentifizierung komplett neu begonnen werden.

Außerdem muss der gesamte zur Authentifizierung gehörende Code besonders gründlich auf Fehler untersucht werden, wobei sowohl Logik- als auch Implementierungsfehler gesucht werden müssen.

4. Preisgabe von Informationen verhindern

Bei allen Maßnahmen muss darauf geachtet werden, dass nicht unbeabsichtigt Informationen preisgegeben werden, die die Unterscheidung zwischen existierenden und nicht existierenden Benutzernamen erlauben. Das kann z.B. bei der Verwendung einer zufällig ausgewählten "geheimen Fragen" passieren: Um zu verhindern, dass ein Angreifer die ausgewählte Frage manipuliert, könnte die zuletzt verwendete Frage im Benutzerprofil gespeichert und solange immer wieder verwendet werden, bis sie korrekt beantwortet wurde. Ein Angreifer, der mit einem Benutzernamen mehrere Authentifizierungsversuche startet, wird dann immer mit der gleichen Frage konfrontiert. Wird ein nicht existierender Benutzername verwendet, gibt es kein Profil mit der zu stellenden Frage, und dem Angreifer wird bei jedem Versuch eine andere Frage gestellt. Dadurch kann zwischen existierenden und nicht existierenden Benutzernamen unterschieden werden.

Um dieses Informationsleck zu schließen, müsste zusätzlicher Aufwand betrieben und auch für nicht existierende, aber bei der Authentifizierung eingegebene Benutzernamen die gestellte Frage gespeichert und bei jedem folgenden Authentifizierungsversuch mit diesem Benutzernamen verwendet werden. Evtl. könnte die Frage auch noch nach einiger Zeit ausgetauscht werden, um eine in der Zwischenzeit erfolgte erfolgreiche Authentifizierung durch den Benutzer zu simulieren. Die Frage ist nur, wie weit dieser Aufwand getrieben werden soll, da es letztlich "nur" darum geht, die Vorbereitung weiterer, ernsthafter Angriffe zu erschweren.

Generell ist es zweckmäßig, einem potentiellen Angreifer so wenig nützliche Informationen wie möglich zu verraten. Dazu gehören sowohl alle Informationen, die Aufschluss über die Existenz oder Nichtexistenz eines Benutzernamens geben als auch Informationen darüber, wo und/oder wieso die Authentifizierung ggf. fehlgeschlagen ist. Dabei sind sowohl sichtbare Fehlermeldungen als auch das nicht sichtbare Verhalten der Webanwendung zu berücksichtigen. Am besten ist es, wenn eine einzige Komponente für die Reaktion auf alle fehlgeschlagenen Authentifizierungsversuche zuständig ist, die darauf mit einer einheitlichen Meldung reagiert. Dadurch wird verhindert, dass sich die Meldungen z.B. durch Tippfehler oder unterschiedliche Formatierungen, versteckte Informationen im HTML-Code, unterschiedliche HTTP-Statuscodes, unterschiedliche Reaktionszeiten etc. unterscheiden (siehe About Security #216).

About Security: Die komplette Serie

Wird ein Konto als Schutz vor Brute-Force-Angriffen nach einer bestimmten Anzahl fehlgeschlagener Authentifizierungsversuche zeitweise gesperrt, darf die entsprechende Fehlermeldung keine Informationen über die Dauer der Sperre oder die Anzahl fehlgeschlagener Authentifizierungsversuche enthalten, damit der Angreifer seinen Angriff nicht danach so anpassen kann, dass die Sperre unterlaufen wird. Wird außerdem ausgegeben, das ein bestimmter Account gesperrt wurde, können darüber existierende Benutzernamen ermittelt werden.

Können sich die Benutzer selbst registrieren, gibt es zwei Möglichkeiten, um das Ermitteln existierender Benutzernamen zu verhindern: Statt die Benutzer die Benutzernamen selbst wählen zu lassen, kann die Webanwendung eindeutige, nicht vorhersagbare (siehe About Security #228) Benutzernamen vergeben. Dadurch wird verhindert, dass beim Versuch, sich mit einem bereits vergebenen Benutzernamen zu registrieren, dieser preis gegeben werden muss. Als zweite Möglichkeit können E-Mail-Adressen als Benutzernamen verwendet werden. Nachdem die Benutzer ihre E-Mail-Adresse angegeben haben, bekommen sie eine E-Mail mit weiteren Anweisungen wie z.B. einem Registrierungslink. Wurde die Adresse zuvor bereits verwendet, kann der Benutzer über den erneuten Registrierungsversuch informiert werden. Ein Angreifer kann so keine existierenden Benutzernamen ermitteln, sofern er nicht auch die Kontrolle über die entsprechenden E-Mail-Accounts hat.

In der nächsten Folge wird die Entwicklung sicherer Authentifizierungssysteme fortgeführt.

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