A01:2025 Mangelhafte Zugriffskontrolle

Hintergrund.

100 % der getesteten Anwendungen wiesen irgendeine Form fehlerhafter Zugriffskontrolle auf. An der Spitze der Top 10 verbleibend, weist diese Kategorie die höchste Anzahl an Vorkommnissen im vorliegenden Datensatz sowie die zweithöchste Anzahl zugehöriger CVEs auf. Bemerkenswerte Common Weakness Enumerations (CWEs) sind CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Insertion of Sensitive Information Into Sent Data, CWE-918: Server-Side Request Forgery (SSRF) und CWE-352: Cross-Site Request Forgery (CSRF).

Punktetabelle.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
40	20.15%	3.74%	100.00%	42.93%	7.04	3.84	1,839,701	32,654

Beschreibung.

Die Zugriffskontrolle erzwingt Richtlinien, sodass Nutzer:innen nicht außerhalb ihrer vorgesehenen Berechtigungen handeln können. Fehler führen in der Regel zur unbefugten Offenlegung, Änderung oder Zerstörung aller Daten oder zur Ausführung einer Geschäftsfunktion außerhalb der Verfügungen der Anwender:innen. Zu den häufigsten Schwachstellen bei der Zugriffskontrolle gehören:

Verstoß gegen die Prinzipien der geringsten Rechte oder der standardmäßigen Verweigerung, bei dem der Zugriff nur für bestimmte Fähigkeiten, Rollen oder Nutzer:innen gewährt werden sollte, aber für jede Person verfügbar ist.
Umgehen von Zugriffskontrollprüfungen durch Ändern der URL (Parametermanipulation oder erzwungenes Durchsuchen), des internen Anwendungsstatus oder der HTML-Seite oder durch Verwendung eines Angriffstools zur Änderung von API-Anfragen.
Ermöglichen, das Konto einer anderen Person anzuzeigen oder zu bearbeiten, indem dessen eindeutige Kennung angegeben wird (unsichere direkte Objektreferenzen).
Eine zugängliche API mit fehlenden Zugriffskontrollen für POST, PUT und DELETE.
Erhöhung der Privilegien. Als Nutzer:in fungieren, ohne angemeldet zu sein oder als Administrator:in fungieren, wenn man als Standard-Nutzer:in angemeldet ist.
Manipulation von Metadaten, wie z. B. das Abfangen oder Manipulieren eines JSON Web Token (JWT)-Zugriffskontrolltokens oder die Manipulation eines Cookies oder eines versteckten Felds, um Berechtigungen zu erhöhen oder die Ungültigerklärung von JWTs zu missbrauchen.
CORS-Fehlkonfiguration ermöglicht API-Zugriff von nicht autorisierten/nicht vertrauenswürdigen Quellen.
Erzwingen des Zugriffs auf authentifizierte Seiten als nicht authentifizierte Person oder zu privilegierten Seiten als Standard-Nutzer:in.

Prävention und Gegenmaßnahmen.

Die Zugriffskontrolle ist nur wirksam bei vertrauenswürdigem serverseitigem Code oder serverlosen APIs, bei denen Angreifer:innen die Zugriffskontrollprüfung oder Metadaten nicht ändern können.

Verweigern Sie standardmäßig den Zugriff, mit Ausnahme öffentlicher Ressourcen.
Implementieren Sie Zugriffskontrollmechanismen einmalig und verwenden Sie diese in der gesamten Anwendung wieder, einschließlich der Minimierung der Nutzung von Cross-Origin Resource Sharing (CORS).
Modellzugriffskontrollen sollten die Datensatzeigentümerschaft erzwingen, anstatt zu akzeptieren, dass Nutzer:innen Datensätze erstellen, lesen, aktualisieren oder löschen können.
Durch Domänenmodelle sollten eindeutige Geschäftslimitanforderungen für Anwendungen durchgesetzt werden.
Deaktivieren Sie die Verzeichnisliste des Webservers und stellen Sie sicher, dass Dateimetadaten (z. B. .git) und Sicherungsdateien nicht in Web-Roots vorhanden sind.
Protokollieren Sie Fehler bei der Zugriffskontrolle und benachrichtigen Sie Administrator:innen bei Bedarf (z. B. wiederholte Fehler).
Setzen Sie Ratenbegrenzung für API- und Controller-Zugriff, um den Schaden durch automatisierte Angriffstools zu minimieren.
Statusbehaftete Sitzungskennungen sollten nach dem Abmelden auf dem Server ungültig gemacht werden. Zustandslose JWT-Token sollten eher kurzlebig sein, damit das Zeitfenster für Angreifer:innen minimiert wird. Für langlebigere JWTs wird dringend empfohlen, die OAuth-Standards zu befolgen, um den Zugriff zu widerrufen.
Verwenden Sie bewährte Toolkits oder Muster, die einfache, deklarative Zugriffskontrollen bieten.

Entwickler:innen und QA-Mitarbeiter:innen sollten funktionale Zugriffskontrolleinheiten und Integrationstests durchführen.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Die Anwendung verwendet nicht überprüfte Daten in einem SQL-Aufruf, der auf Kontoinformationen zugreift:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

Angreifer:innen ändern einfach den „acct“-Parameter des Browsers, um die gewünschte Kontonummer zu senden. Bei nicht korrekter Überprüfung kann die/der Angreifer:in auf das Konto einer beliebigen Nutzer:in zugreifen.

https://example.com/app/accountInfo?acct=notmyacct

Szenario Nr. 2: Angreifer:innen erzwingen einfach die Suche nach Ziel-URLs. Für den Zugriff auf die Admin-Seite sind Admin-Rechte erforderlich.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Wenn eine nicht authentifizierte Benutzer:in auf eine der Seiten zugreifen kann, liegt ein Fehler vor. Wenn ein Benutzer:in ohne Administrationsrechte auf die Admin-Seite zugreifen kann, handelt es sich um einen Fehler.

Szenario Nr. 3: Eine Anwendung verwaltet ihre gesamte Zugriffskontrolle im Frontend. Während die/der Angreifer:in aufgrund von im Browser ausgeführtem JavaScript-Code nicht auf https://example.com/app/admin_getappInfo zugreifen kann, kann sie/er einfach Folgendes ausführen:

$ curl https://example.com/app/admin_getappInfo

von der Kommandozeile aus.