Coder Conquer Security OWASP Top 10 API-Serie — Autorisierung auf unterbrochener Objektebene

Bedrohungen der Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass es fast unmöglich geworden ist, nach der Bereitstellung von Programmen mit ihnen Schritt zu halten. Im Zeitalter von DevSecOps, kontinuierlicher Bereitstellung und mehr Daten als je zuvor helfen kluge Unternehmen ihren Entwicklern jedoch dabei, sich zu sicherheitsbewussten Superstars weiterzubilden, die dabei helfen, häufig auftretende Sicherheitslücken zu beseitigen, bevor sie überhaupt in die Produktion gelangen. Wir haben uns damit befasst Sicherheitslücken im Internet, plus unser eigenes Die 8 wichtigsten Infrastrukturen als Code Bugs, und jetzt ist es an der Zeit, sich mit der nächsten großen Softwaresicherheitsherausforderung vertraut zu machen. Bist du bereit?

Diese nächste Blogserie wird sich auf einige der schlimmsten Sicherheitslücken konzentrieren, die sich auf Anwendungsprogrammierschnittstellen (APIs) beziehen. Diese sind so schlimm, dass sie das Open Web Application Security Project ins Leben gerufen haben (WESPE) Liste der wichtigsten API-Schwachstellen. Angesichts der Bedeutung von APIs für moderne Computerinfrastrukturen handelt es sich um kritische Probleme, die Sie um jeden Preis von Ihren Anwendungen und Programmen fernhalten müssen.

Ein perfektes Beispiel dafür, warum es wichtig ist, Code zur Durchsetzung der Sicherheit zu verwenden, findet sich in einer Untersuchung der Sicherheitsanfälligkeit für eine fehlerhafte Autorisierung auf Objektebene. Dies passiert, wenn Programmierer nicht explizit definieren, welche Benutzer Objekte und Daten anzeigen können, oder wenn sie irgendeine Form der Überprüfung vornehmen, um Objekte anzusehen, zu ändern oder andere Anfragen zu stellen, um sie zu manipulieren oder auf Objekte zuzugreifen, sodass sie Objekte und Daten über API-Endpunkte ändern und darauf zugreifen können. Ein API-Endpunkt ist ein Kontaktpunkt, 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 Softwareprogramme der Welt verbessert, aber es besteht das Risiko, dass mehrere Endpunkte offengelegt werden, wenn sie nicht luftdicht sind.

Es kann auch vorkommen, dass Programmierer Eigenschaften von übergeordneten Klassen vergessen oder erben, ohne zu wissen, dass dadurch auch ein kritischer Überprüfungsprozess in ihrem Code ausgelassen wird. Im Allgemeinen sollten Autorisierungsprüfungen auf Objektebene für jede Funktion vorgesehen werden, die mithilfe einer Benutzereingabe auf eine Datenquelle zugreift.

Denken Sie, Sie kennen sich bereits mit diesen aus und können einen Fehler in der Zugriffskontrolle sofort finden, beheben und beheben? Spiele die spielerische Herausforderung:

Wie ist es dir ergangen? Wenn du an deinem Ergebnis arbeiten willst, lies weiter!

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

Sicherheitslücken bei der Zugriffskontrolle auf Objektebene ermöglichen es Angreifern, Maßnahmen zu ergreifen, zu denen sie nicht zugelassen werden sollten. Dabei kann es sich um eine Aktion handeln, die Administratoren vorbehalten sein sollte, wie etwa der Zugriff auf oder das Anzeigen vertraulicher Daten oder das Löschen von Datensätzen. In einer hochsicheren Umgebung kann dies sogar bedeuten, dass niemand die Aufzeichnungen überhaupt einsehen kann, sofern er nicht ausdrücklich dazu autorisiert ist.
Bei der Definition der Autorisierung auf Objektebene sollten Sie alle möglichen Aktionen berücksichtigen. In der Java Spring API könnte ein Endpunkt mit einem potenziellen Problem beispielsweise so aussehen:

public boolean deleteOrder (Lange ID) {
Bestellung = OrderRepository.getOne (id);
wenn (Reihenfolge == null) {
log.info („Keine Bestellung gefunden“);
gib falsch zurück;
}
Benutzerbenutzer = order.getUser ();
OrderRepository.delete (Bestellung);
log.info („Bestellung für Benutzer {} löschen“, user.getId ());
gib wahr zurück;

Der API-Endpunkt löscht Bestellungen anhand der ID, überprü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.

Damit sichere Zugriffsbeschränkungen ordnungsgemäß implementiert werden können, würde der Code eher so aussehen:

public boolean deleteOrder (Lange ID) {
Benutzerbenutzer = UserService.getUserByContext ();
boolean orderExist = getUserOrders () .stream ()
.anyMatch (order -> (order.getId () == id));
wenn (OrderExist) {
orderrepository.deleteById (id);
log.info („Bestellung für Benutzer {} löschen“, user.getId ());
gib wahr zurück;
} sonst {
log.info („Keine Bestellung gefunden“);
gib falsch zurück;

Beseitigung von Sicherheitslücken bei der Autorisierung auf Objektebene

Der Zugriffskontrollcode muss nicht übermäßig kompliziert sein. Im Fall unseres Beispiels für eine Java-Spring-API-Umgebung kann dies behoben werden, indem genau definiert wird, wer auf Objekte zugreifen kann.

Zunächst muss ein Überprüfungsprozess implementiert werden, um festzustellen, wer die Anfrage stellt:

Benutzerbenutzer = 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));

Und schließlich löschen wir das Objekt:

orderrepository.deleteById (id);

Denken Sie daran, dass Sie sicherstellen müssen, dass die Autorisierungsmethode in Ihrem Code den Benutzerrichtlinien und Datenzugriffskontrollen Ihres Unternehmens entspricht. Um sicherzustellen, dass Ihr Code vollständig sicher ist, sollten Sie Prüfungen durchführen, um sicherzustellen, dass Benutzer mit unterschiedlichen Berechtigungsstufen Zugriff auf die Daten haben, die sie für ihre Arbeit benötigen, aber daran gehindert werden, Inhalte einzusehen oder zu ändern, die auf sie beschränkt sein sollten. Dadurch könnten Sicherheitslücken bei der Steuerung fehlender Objekte aufgedeckt werden, die versehentlich übersehen wurden.

Die wichtigsten Erkenntnisse aus diesen Beispielen bestehen darin, zunächst jede Aktion zu definieren, die ein Benutzer mit einem Objekt ausführen könnte, und dann dem Code direkt starke Zugriffskontrollen hinzuzufügen. Und schließlich sollten Sie niemals darauf vertrauen, dass die vererbten übergeordneten Eigenschaften diese Aufgabe erledigen oder diese Autorität an eine andere Stelle delegieren. Definieren Sie stattdessen Benutzerberechtigungen und Aktionen im Code explizit für jeden Objekttyp, den Sie schützen müssen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.