Der 5. Platz der OWASP Top-10, den 10 am meisten ausgenutzten Schwachstellen bei Webanwendungen, nennt sich „Broken Access Control“ – übersetzt mit „Fehlerhafte Autorisierung“
Beim Thema Autorisierung geht es um die Problemstellung, wie man verhindern kann, dass Hacker in meinem Namen Geld überweisen oder Einkäufe durchführen.
Oder auch: wie kann man verhinden, dass in meinem Namen ohne mein Wissen bösartige oder beleidigende Postings veröffentlicht werden.
Was ist Autorisierung?
Autorisierung bewirkt, dass der Benutzer nur innerhalb der beabsichtigten Berechtigungen agieren kann. Zur Abgrenzung: Authentifizierung ist ja das Beweisen bzw. Ausweisen, dass man derjenige ist, der man zu sein vorgibt.
Bei der Autorisierung wird geprüft und sichergestellt, dass ich als authentifizierter Benutzer auch das tun darf, wozu ich berechtigt bin bzw. dass andere das nicht dürfen, wenn sie nicht berechtigt sind. z.B. auf meine Daten zugreifen, lesend oder schreibend oder Transaktionen durchführen – wie Überweisungen von meinem Konto tätigen
Oder in einem komplexeren Softwaresystem wie einem Bestellprozess, dass jemand eine Bestellung prüfen und freigeben muss, es also einen Genehmigungsprozess gibt, und dann jemand die Bestellung bearbeiten kann.
All das ist eng mit Autorisierung verbunden, dass also geprüft und verwaltet wird: „wer darf was“
Häufige Fehler
3 häufige Fehler beim Umsetzen der Autorisierung sind folgende.
Verwenden von IDs in Request Parametern
Man muss sich immer vor Augen halten: alles was vom Client (Browser) kommt, kann manipuliert werden. Wenn in Requestparametern IDs verwendet werden, können die von Angreifern geändert werden. Das darf nicht dazu führen, dass ungeprüft auf andere Daten zugegriffen werden kann, für die keine Berechtigung besteht. Deshalb: immer serverseitig nochmals prüfen, und am besten keine IDs verwenden, die Rückschlüsse auf echte Daten zulassen, wie Kontonummern, usw.
IDs für GUI-Elemente sollten keine echten IDs der realen Objekte sein. Statt dessen sollte man Serverseiting ein Mapping verwenden, so dass man dort den Bezug herstellen kann
Verstecken von Webseiten, für die keine Berechtigung besteht
Nur weil der Link auf eine Seite nicht in Menü erscheint, heisst nicht, dass jemand die Seite nicht findet. Deshalb sollte immer serverseitig und bei jedem Request geprüft werden, ob der Benutzer das darf was er verlangt. Immer und bei jedem Request – ausser bei öffentlichen Ressourcen, auf die jeder zugreifen darf
Automatisierte Angriffe
Beim „Brute Forcing“ versucht der Angreifer einfach Hunderttausende von Passwörtern durch. Wird das nicht verhindert, führt das sehr oft zum Erfolg. Abhilfe schafft hier eine Ratenbeschränkung: wurde PW 5 mal falsch eingegeben, dann Benutzer für 10 Minuten sperren.
Bei der Angriffstechnik „Credential Stuffing“ hat der Angreifer hat eine gültige Liste mit Benutzernamen und Passwörtern von anderen gekaperten Systemen. Der Angreifer setzt darauf, dass viele Benutzer diese auch für andere Systeme einsetzen.
Das Erkennen eines Credential Stuffing Angriffs sehr schwer, da pro Benutzeraccount nur 1 mal das PW falsch eingegeben wird, danach wird der nächste Benutzeraccount ausprobiert. Man kann also nicht feststellen wie beim Brute Forcing, dass ein PW 5 mal falsch eingegeben wird. Man kann höchstens feststellen, dass von 1 IP-Adresse viele Accounts durchprobiert werden. Bei Firmen gehen allerdings hunderte Mitarbeiter über eine einzige IP-Adresse nach draußen (Proxy) – deshalb ist diese Methode nicht zuverlässig.
Schwachstellen erkennen
Automatisierte Tests sind bei diesem Thema nicht gut geeignet. Manuelles Testen (also Pentesting) ist hier der beste Weg, um fehlende oder ineffektive Zugriffskontrollen zu erkennen. Außerdem ist hier ein Quellcodecode-Review immer sehr hilfreich, um nachzusehen, nach welchem Pattern das implementiert ist bzw. ob überhaupt ein übergreifendes Pattern benutzt wird.
Prävention
Wie immer einige Tipps aus der Secure Coding Schulung
Autorisierung immer Serverseitig überprüfen, denn der Client ist nicht vertrauenswürdig, da er manipuliert werden kann. Außerdem muss bei wirklich jedem Http-Request geprüft werden, und nicht nur einmal am Anfang. Eine Ausnahme sind öffentliche Ressourcen, wie Webseiten, die man auch sehn kann, ohne eingeloggt zu sein.
Keine geheimen IDs oder Passwörter im Quellcode. Wenn der Quellcode oder auch der Binärcode abhanden kommt, dann können diese relativ einfach ausgelesen werden. Alle Geheimnisse liegen damit offen, so dass man das unbedingt vermeiden sollte. Passwörter gehören also ausgelagert in einen sichern Keystore, so wie wir es auch schon bei A3:2017 besprochen haben.
Passendes Berechtigungs-Modell wählen. Beim Programmieren muss ja letztendlich geprüft werden, wer welche Funktionen ausführen darf und wer nicht. Um hier eine klare Linie in den Code zu bekommen, braucht man ein geeignetes Berechtigungsmodell.
Bewährt hat sich in vielen Fällen ein rollenbasiertes Berechtigungsmodell, bei der im Code auf die Berechtigungen geprüft wird. Die Berechtigungen werden dann einer oder mehreren Rollen zugeordnet, und zwar ausserhalb des Codes, am besten in der Datenbank. Die Rollen werden dann letztendlich den Benutzern zugewiesen. So kann man die Übersicht behalten und hat eine klare Linie drin.
Bei rollenbasierten Berechtigungssystem wird also immer nur die Berechtigung geprüft, nicht die Rolle oder gar der Benutzer. Durch diese Indirektion schafft man die nötige Flexibilität bei der Programmierung.
Bei Java verwende ich übrigens dafür sehr gerne das Apache Shiro Framework, da es auch entitätsgebundene Berechtigungen zulässt.
Weitere Tipps zur Prävention lernt ihr in der SC Schulung, z.B. der Umgang mit Sessions, Autorisierungs-Token und Möglichkeiten für die Verteidigung bei automatisierten Angriffen
Fazit
Beim 5. Platz der OWASP Top-10 geht’s um die Autorisierung, die sehr oft fehlerhaft ist, oder einfach falsch umgesetzt wird. Zu viele Webanwendungen nehmen das Thema nicht ernst genug und setzen so die Daten Ihrer Anwender aufs Spiel, oder auch Ihr Geld oder Ihren guten Ruf, wenn z.B. in Ihren Namen schlimme Dinge getan werden.
Deshalb heißt es für uns Entwickler hier „aufpassen“, denn wenn an dieser Stelle Fehler gemacht werden, ist das für unsere Webanwendung katastrophal und manchmal sogar existenzbedrohend.
Wenn Ihr mehr über dieses Thema lernen wollt, dann kommt gerne in meine Secure Coding Schulung, wo wir auch zu diesem Thema Übungen im Praxisteil machen.
