OWASP Top Ten 2017 (de)

A5:2017-Fehler in der Zugriffskontrolle

 Languages: en [de]
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 2 Verbreitung: 2 Auffindbarkeit: 2 technisch: 3 Geschäftl. ?
Es gehört zu den Kernfähigkeiten von Angreifern, Zugangskontrollen zu umgehen. Während SAST und DAST fehlende Zugangskontrollen erkennen, können sie nicht prüfen, ob vorhandene Kontrollen korrekt funktionieren. Dies kann manuell erkannt werden; in manchen Frameworks sind fehlende Zugangskontrollen automatisiert erkennbar.
Auf Grund fehlender automatisierter Erkennung bzw. fehlender Funktionstests in der Entwicklung sind Schwachstellen bei der Zugriffskontrolle häufig.
Generell sind statische oder dynamische Tests nicht für die Erkennung von Zugangskontrollen geeignet. Manuelles Testen ist der beste Weg, um fehlende oder ineffektive Zugriffskontrollen zu erkennen, einschließlich HTTP-Methoden (GET vs. PUT etc.), Controller, direkte Objektreferenzen etc.
Als technische Auswirkungen können Angreifer als andere Benutzer oder Administratoren agieren, bzw. können Angreifer privilegierte Funktionen nutzen, Datensätze erstellen, aufrufen, aktualisieren oder löschen.
Die Auswirkungen auf das Unternehmen hängen vom Schutzbedarf der Anwendung und ihrer Daten ab.
Ist die Anwendung verwundbar?
Zugriffskontrollmechanismen setzen Richtlinien um, so dass Benutzer nur innerhalb ihrer beabsichtigten Berechtigungen handeln können. Fehlerfälle führen hier in der Regel zu unbefugter Offenlegung, Änderung oder Löschung von Daten oder zu einer Geschäftshandlung außerhalb der Befugnisse des Benutzers. Zu den häufigsten Schwachstellen gehören:
* Umgehen von Zugriffskontrollprüfungen durch Ändern der URL, des internen Anwendungsstatus oder der HTML-Seite oder einfach durch Verwendung eines API-Angriffswerkzeugs.
* Änderbarkeit des Primärschlüssels zu dem eines anderen Benutzers, so dass das Konto dieses Benutzers angezeigt oder bearbeitet werden kann.
* Rechteausweitung: Als Benutzer handeln, ohne angemeldet zu sein oder als Administrator handeln, wenn man als Benutzer angemeldet ist.
* Metadatenmanipulationen, wie z.B. das erneute Verwenden/Manipulieren eines JSON Web Tokens (JWT), Zugriffskontroll-Tokens, Cookies oder versteckten Feldes, um Berechtigungen auszuweiten oder der Missbrauch der JWT-Invalidierung.
* Fehlkonfigurationen von CORS ermöglichen einen unbefugten API-Zugriff.
* Aufrufen authentifizierter Seiten als nicht authentifizierter Benutzer oder privilegierter Seiten als Standardbenutzer. Zugriff auf die API durch fehlenden Zugriffskontrollen für POST, PUT und DELETE.
Wie kann ich das verhindern?
Eine Zugriffskontrolle ist nur wirksam, wenn sie im vertrauenswürdigen serverseitigen Code oder über eine Serverless API betrieben wird, so dass der Angreifer die Zugriffskontrollprüfung oder die verwendeten Metadaten nicht manipulieren kann.
* Mit Ausnahme von Zugriffen auf öffentliche Ressourcen sollten Anfragen standardmäßig verweigert werden.
* Zugriffskontrollmechanismen sollten einmalig implementiert und in der gesamten Anwendung wiederverwendet werden. Dies bedeutet auch eine CORS-Minimierung.
* Zugriffskontrollmechanismen müssen die Berechtigung für Datensätzen anhand des Dateneigners kontrollieren anstatt zu akzeptieren, dass Benutzer beliebige Datensätze erstellen, lesen, aktualisieren oder löschen können.
* Sich gegenseitig ausschließende Rechte sollten durch Berechtigungskonzepte durchgesetzt werden.
* Deaktivierung von Verzeichnisauflistungen bei Webservern und Sicherstellen, dass keine Meta- und Backupdateien (z.B. .git) in Web-Roots abgelegt werden.
* Zugriffsfehler müssen protokolliert und ggf. Administratoren alarmiert werden (z.B. bei wiederholten Fehlern).
* API- und Controller-Zugriffe über Quotas beschränken, um den Schaden durch automatisierte Angriffs-Tools zu minimieren.
* JWT-Token sollten nach dem Abmelden auf dem Server invalidiert werden. Entwickler und QS-Teams sollten die Zugangskontrolle in funktionalen Unit- u. Integrationstests einbeziehen.
Mögliche Angriffsszenarien
Szenario 1: Eine Anwendung verarbeitet nicht verifizierte Daten in einem SQL-Aufruf, der auf Kontoinformationen zugreift:
pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );
 Ein Angreifer ändert nun den Parameter “acct” im Browser in eine beliebige Kontonummer. Werden Eingangsdaten nicht ordnungsgemäß verifiziert, kann ein Angreifer auf das Konto eines beliebigen Benutzers zugreifen.
http://example.com/app/accountInfo?acct=notmyacct
Szenario 2: Szenario 2: Ein Angreifer erzwingt den Aufruf einer Ziel-URL. Für den Zugriff auf die Admin-Seite sind Administratorrechte erforderlich.
http://example.com/app/getappInfo
 http://example.com/app/admin_getappInfo
 Wenn ein unauthentifizierter Benutzer auf eine der beiden URLs zugreifen kann, liegt ein Fehlerfall vor. Wenn ein Nicht-Administrator auf die Admin-Seite zugreifen kann, ist dies ebenfalls ein Fehler.
Referenzen