Coders Conquer Security OWASP Top 10 API-Serie – Broken Object Level Authorization

Cyber-Bedrohungen sind heutzutage allgegenwärtig und unerbittlich. Die Lage ist so ernst, dass es nahezu unmöglich geworden ist, nach der Bereitstellung von Programmen mit ihnen Schritt zu halten. Doch im Zeitalter von DevSecOps, Continuous Delivery und einer beispiellosen Datenflut helfen kluge Unternehmen ihren Entwicklern dabei, sich zu sicherheitsbewussten Experten weiterzuentwickeln, die gängige Schwachstellen bereits vor der Produktion eliminieren. Wir haben uns bereits mit Web-Schwachstellen sowie unseren eigenen Top 8 Infrastructure-as-Code-Fehlern befasst – nun ist es an der Zeit, sich der nächsten großen Herausforderung der Softwaresicherheit zu stellen. Sind Sie bereit?

Diese Blog-Serie konzentriert sich auf einige der kritischsten Sicherheitslücken in Bezug auf Application Programming Interfaces (APIs). Diese sind so gravierend, dass sie es auf die Liste der Top-API-Schwachstellen des Open Web Application Security Project (OWASP) geschafft haben. Angesichts der Bedeutung von APIs für moderne IT-Infrastrukturen handelt es sich um kritische Probleme, die Sie unter allen Umständen aus Ihren Anwendungen und Programmen heraushalten müssen.

Ein perfektes Beispiel dafür, warum die Durchsetzung von Sicherheit durch Code unerlässlich ist, bietet die Schwachstelle „Broken Object Level Authorization“. Sie tritt auf, wenn Programmierer versäumen, explizit festzulegen, welche Benutzer Objekte und Daten einsehen dürfen, oder keine Form der Verifizierung für das Anzeigen, Ändern oder Manipulieren von Objekten bereitstellen. Dies ermöglicht es Angreifern, über API-Endpunkte auf Objekte und Daten zuzugreifen oder diese zu verändern. Ein API-Endpunkt ist ein Kontaktpunkt, oft eine URL, der für die Kommunikation zwischen der API und einem anderen System genutzt wird. Die Konnektivität zwischen Apps hat einige der weltweit beliebtesten Softwarelösungen hervorgebracht, birgt jedoch das Risiko, dass mehrere Endpunkte exponiert werden, wenn sie nicht absolut sicher sind.

Dies kann auch geschehen, wenn Programmierer Eigenschaften von übergeordneten Klassen übernehmen oder vergessen, ohne zu realisieren, dass dadurch ein kritischer Verifizierungsprozess im Code fehlt. Generell sollten Autorisierungsprüfungen auf Objektebene für jede Funktion enthalten sein, die unter Verwendung von Benutzereingaben auf eine Datenquelle zugreift.

Sie glauben, Sie kennen sich bereits aus und können eine Zugriffskontroll-Schwachstelle sofort finden, beheben und eliminieren? Testen Sie Ihr Wissen in unserer spielerischen Challenge:

Wie haben Sie abgeschnitten? Wenn Sie Ihr Ergebnis verbessern möchten, lesen Sie einfach weiter!

Was sind Beispiele für Schwachstellen durch Broken Object Level Authorization?

Schwachstellen bei der Zugriffskontrolle auf Objektebene ermöglichen es Angreifern, Aktionen auszuführen, zu denen sie nicht berechtigt sein sollten. Dies können Aktionen sein, die Administratoren vorbehalten sind, wie der Zugriff auf sensible Daten oder das Löschen von Datensätzen. In einer hochsicheren Umgebung kann dies sogar bedeuten, dass niemand Datensätze einsehen darf, sofern er nicht explizit dazu autorisiert ist.
Sie sollten bei der Definition der Autorisierung auf Objektebene alle möglichen Aktionen berücksichtigen. In einer Java-Spring-API könnte ein Endpunkt mit einem potenziellen Problem beispielsweise so aussehen:

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

Der API-Endpunkt löscht Bestellungen anhand der ID, prüft jedoch nicht, ob diese Bestellung vom aktuell angemeldeten Benutzer getätigt wurde. Dies bietet einem Angreifer die Möglichkeit, diese Lücke auszunutzen und die Bestellungen anderer Benutzer zu löschen.

Für eine ordnungsgemäß implementierte, sichere Zugriffsbeschränkung sollte der Code eher so aussehen:

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Eliminierung von Schwachstellen durch Broken Object Level Authorization

Der Code für die Zugriffskontrolle muss nicht übermäßig kompliziert sein. Im Fall unseres Java-Spring-API-Beispiels lässt sich das Problem beheben, indem präzise definiert wird, wer auf welche Objekte zugreifen darf.

Zunächst muss ein Verifizierungsprozess implementiert werden, um zu identifizieren, wer die Anfrage stellt:

User user = userService.getUserByContext();

Als Nächstes müssen wir sicherstellen, dass die Objekt-ID existiert und dem Benutzer gehört, der die Anfrage stellt:

boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));

Abschließend fahren wir mit dem Löschen des Objekts fort:

orderRepository.deleteById(id);

Denken Sie daran, dass die Autorisierungsmethode in Ihrem Code mit den Benutzerrichtlinien und Datenzugriffskontrollen Ihres Unternehmens übereinstimmen muss. Um die Sicherheit Ihres Codes zu gewährleisten, sollten Sie prüfen, ob Benutzer mit unterschiedlichen Berechtigungsstufen Zugriff auf die für ihre Arbeit erforderlichen Daten haben, während sie gleichzeitig daran gehindert werden, eingeschränkte Inhalte einzusehen oder zu ändern. Dies kann Schwachstellen bei der Objektkontrolle aufdecken, die versehentlich übersehen wurden.

Die wichtigsten Erkenntnisse aus diesen Beispielen sind: Definieren Sie zunächst jede Aktion, die ein Benutzer mit einem Objekt ausführen könnte, und implementieren Sie dann strikte Zugriffskontrollen direkt im Code. Vertrauen Sie schließlich niemals darauf, dass vererbte übergeordnete Eigenschaften diese Aufgabe übernehmen oder diese Autorität an anderer Stelle delegiert wird. Definieren Sie stattdessen Benutzerberechtigungen und Aktionen explizit im Code für jeden Objekttyp, den Sie schützen müssen.

Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Secure Code Warrior-Schulungsplattform ausprobieren, um Ihre Cybersicherheitskenntnisse stets auf dem neuesten Stand zu halten.