Sichere Websites mit den OWASP Top 10: Fehlerhafte Autorisierung auf Anwendungsebene

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:

Fehlerhafte Autorisierung auf Anwendungsebene

Auf Platz 7 der OWASP Top 10 ist die Fehlerhafte Autorisierung auf Anwendungsebene. Hinter dem langem Titel verbirgt sich das Ausnutzen von Funktionen, auf die man keine Berechtigung hätte. Beispielsweise haben gewisse Websites einen Link zur Admin-Konsole im Footer, der auch angezeigt wird, wenn man nicht angemeldet ist. Noch schlimmer, wenn der Link tatsächlich funktioniert und jeder Benutzer ohne Authentifizierung in den Admin-Bereich gelangt.

Grundsätzlich soll eine Anwendung nur Aktionen darstellen (Links, Buttons, ...), die ein Benutzer auch ausführen darf. Zudem muss Serverseitig überprüft werden, ob der konkrete Benutzer auch die Berechtigung hat, die Aktion auszuführen. Eine Clientseitige überprüfung ist nicht ausreichend.

Die serverseitige Authentifizierung darf sich nicht auf Daten verlassen, die ein Client manipulieren könnte. Beispielsweise wenn die Benutzer ID über die URL oder als Cookie mitgegeben wird, so à la url/do_action?userId=admin.

Mit Fehlerhafte Autorisierung auf Anwendungsebene sind aber nicht nur Funktionen gemeint, die aufgerufen werden können. Diagnose-, Log- oder Systeminformationen dürfen ebenfalls nicht ohne ausreichende Berechtigung eingesehen werden.

Erstellen Sie für Ihre Software eine zentrale und konsistente Definition eines Autorisationsmodells. Definieren Sie Rollen (z.B. Administrator, Publisher, Guest, etc.) und weisen Sie ihre Benutzer einer Rolle zu (Mitgliedschaft).

Überprüfen Sie, ob Standardressourcen von verwendeten Frameworks und Bibliotheken erreichbar sind und was für Benutzerrechte dafür nötig sind. Ein typisches Beispiel in der .NET Welt ist die Datei elmah.axd des gleichnamigen Logging Frameworks, die zu oft öffentlich einsehbar ist.

Testen Sie ihre Applikation mit mehreren Benutzern aus allen möglichen Rollen und überprüfen Sie, welche Seiten und Aktionen sichtbar sind. Das lässt sich mit Scannern auch automatisieren.

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.