Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass der Versuch, mit ihnen Schritt zu halten, nachdem Programme bereitgestellt wurden, fast unmöglich geworden ist. Im Zeitalter von DevSecOps, Continuous Delivery und mehr Daten als je zuvor helfen kluge Unternehmen ihren Entwicklern, sich zu sicherheitsbewussten Superstars zu entwickeln, die dabei helfen, häufige Schwachstellen zu beseitigen, bevor sie in die Produktion gelangen. Wir haben uns mit Web-Schwachstellen und unseren eigenen Top 8 Infrastructure as Code-Bugs befasst, und jetzt ist es an der Zeit, sich mit der nächsten großen Software-Sicherheitsherausforderung vertraut zu machen. Sind Sie bereit?

Diese nächste Blogserie konzentriert sich auf einige der schlimmsten Sicherheitslücken im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es auf die Liste der Top-API-Schwachstellen des Open Web Application Security Project(OWASP) geschafft haben. Wenn man bedenkt, wie wichtig APIs für moderne Computerinfrastrukturen sind, sind dies kritische Probleme, die Sie um jeden Preis aus Ihren Anwendungen und Programmen heraushalten müssen.

Ein perfektes Beispiel dafür, warum es unerlässlich ist, Code zu verwenden, um die Sicherheit zu erzwingen, findet sich in einer Untersuchung der Schwachstelle "broken object level authorization". Dies geschieht, wenn Programmierer nicht explizit definieren, welche Benutzer in der Lage sind, Objekte und Daten anzuzeigen oder irgendeine Form der Überprüfung vorzunehmen, um Objekte anzuzeigen, zu ändern oder andere Anfragen zur Manipulation oder zum Zugriff auf Objekte zu stellen, so dass sie Objekte und Daten über API-Endpunkte ändern und darauf zugreifen können. Ein API-Endpunkt ist ein Berührungspunkt, oft eine URL, der für die Kommunikation zwischen der API selbst und einem anderen System verwendet wird. Die Fähigkeit zur Konnektivität zwischen Apps hat einige der beliebtesten Software der Welt aufgewertet, aber sie geht mit dem Risiko einher, dass mehrere Endpunkte offengelegt werden, wenn sie nicht luftdicht sind.

Es kann auch vorkommen, dass Programmierer Eigenschaften von übergeordneten Klassen vergessen oder erben, ohne sich darüber im Klaren zu sein, dass sie damit auch einen kritischen Überprüfungsprozess innerhalb ihres Codes auslassen. Generell sollten Berechtigungsprüfungen auf Objektebene für jede Funktion enthalten sein, die über eine Eingabe des Benutzers auf eine Datenquelle zugreift.

Sie denken, Sie kennen diese bereits und können einen Fehler in der Zugangskontrolle sofort finden, beheben und beseitigen? Spielen Sie die gamifizierte Herausforderung:

Wie haben Sie abgeschnitten? Wenn Sie an Ihrem Ergebnis arbeiten wollen, lesen Sie weiter!

Was sind einige Beispiele für Sicherheitslücken bei der Autorisierung auf Objektebene?

Schwachstellen in der Zugriffskontrolle auf Objektebene ermöglichen es Angreifern, Aktionen auszuführen, die ihnen nicht erlaubt sein sollten. Dabei kann es sich um Aktionen handeln, die Administratoren vorbehalten sein sollten, wie z. B. der Zugriff auf oder die Anzeige von sensiblen Daten oder das Zerstören von Datensätzen. In einer hochsicheren Umgebung könnte es sogar bedeuten, dass niemand Datensätze einsehen darf, es sei denn, er ist ausdrücklich dazu autorisiert.
Sie sollten alle möglichen Aktionen im Auge behalten, wenn Sie die Autorisierung auf Objektebene definieren. In Java Spring API könnte ein Endpunkt mit einem potenziellen Problem zum Beispiel 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 nach ID, prüft aber nicht, ob diese Bestellung von dem aktuell angemeldeten Benutzer getätigt wurde. Dies stellt eine Möglichkeit für einen Angreifer dar, diese Lücke auszunutzen und die Bestellungen anderer Benutzer zu löschen.

Um sichere Zugriffsbeschränkungen richtig zu implementieren, würde der Code eher wie folgt 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 bei der Autorisierung auf Objektebene

Der Code für die Zugriffskontrolle muss nicht übermäßig kompliziert sein. Im Fall unseres Beispiels einer Java-Spring-API-Umgebung kann er durch eine enge Definition, wer auf Objekte zugreifen darf, festgelegt werden.

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

Benutzer user = userService.getUserByContext();

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

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

Und schließlich fahren wir fort, das Objekt zu löschen:

orderRepository.deleteById(id);

Denken Sie daran, dass Sie sicherstellen müssen, dass die Autorisierungsmethode in Ihrem Code mit den Benutzerrichtlinien und Datenzugriffskontrollen Ihrer Organisation übereinstimmt. Um sicherzustellen, dass Ihr Code vollständig sicher ist, sollten Sie Prüfungen durchführen, um zu verifizieren, dass Benutzer mit verschiedenen Berechtigungsstufen Zugriff auf die Daten haben, die sie für ihre Arbeit benötigen, aber daran gehindert werden, etwas anzuzeigen oder zu ändern, das auf sie beschränkt sein sollte. Auf diese Weise werden möglicherweise Schwachstellen in der Objektsteuerung aufgedeckt, die versehentlich übersehen wurden.

Die wichtigsten Erkenntnisse aus diesen Beispielen sind, zuerst jede Aktion zu definieren, die ein Benutzer mit einem Objekt durchführen könnte, und dann starke Zugriffskontrollen direkt in den Code einzufügen. Und schließlich sollten Sie niemals darauf vertrauen, dass die vererbten übergeordneten Eigenschaften diese Aufgabe übernehmen oder diese Berechtigung an andere Stellen delegieren. Definieren Sie stattdessen Benutzerberechtigungen und Aktionen im Code explizit für jeden Objekttyp, den Sie schützen müssen.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.