262-000177-001 OWASP Top 10 für API-Sicherheit
„
Produktinformationen
Technische Daten
- Produktname: Entwicklerhandbuch zu den OWASP Top 2023 für API 10
Sicherheit - Inhalt: API-Sicherheits-Spickzettel, Definitionen und detaillierte
Leitfäden für die OWASP Top 2023 für API-Sicherheit 10
Anweisungen zur Produktverwendung
Einführung in die API-Sicherheit
Der Entwicklerleitfaden bietet umfassende Informationen zu den
OWASP Top 2023 für API-Sicherheit 10 mit Schwerpunkt auf allgemeiner Sicherheit
Risiken bei der Entwicklung von Anwendungen mit APIs.
Spickzettel zur API-Sicherheit
Der Spickzettel listet die folgenden Kategorien der API-Sicherheit auf
Risiken:
- Autorisierung auf Ebene defekter Objekte
- Fehlerhafte Authentifizierung
- Autorisierung auf Eigenschaftsebene für defekte Objekte
- Unbegrenzter Ressourcenverbrauch
- Beschädigte Funktionsebenenautorisierung
- Uneingeschränkter Zugriff auf sensible Geschäftsabläufe
- Serverseitige Anforderungsfälschung
- Sicherheitsfehlkonfiguration
- Unsachgemäße Bestandsverwaltung
- Unsicherer Einsatz von APIs
Entwicklerhandbuch Überview
Der Leitfaden befasst sich eingehend mit den einzelnen API-Sicherheitsrisikokategorien und bietet
detaillierte Erklärungen und Anleitungen zur Lösung und Minderung
diese Risiken wirksam zu bekämpfen.
Häufig gestellte Fragen (FAQ)
F: Warum ist API-Sicherheit wichtig?
A: API-Sicherheit ist von entscheidender Bedeutung, da APIs oft vertrauliche Daten offenlegen
und Anwendungslogik, was sie zu Hauptzielen für Angreifer macht.
Die Sicherung von APIs ist unerlässlich, um Datenlecks zu verhindern und
Gewährleistung der allgemeinen Systemsicherheit.
F: Wie kann ich sichere APIs implementieren?
A: Um sichere APIs zu implementieren, befolgen Sie bewährte Methoden wie:
ordnungsgemäße Authentifizierung, Autorisierungsmechanismen, Eingabevalidierung,
Verschlüsselung sensibler Daten sowie regelmäßige Sicherheitsüberprüfungen und
Aktualisierungen.
„`
WEISSES PAPIER
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
Inhalt
Spickzettel zur API-Sicherheit
5
Definitionen
5
API1:2023 – Autorisierung auf Ebene defekter Objekte
7
API2:2023 – Defekte Authentifizierung
8
API3:2023–Autorisierung auf Eigenschaftsebene für defekte Objekte
9
API4:2023 – Uneingeschränkter Ressourcenverbrauch
11
API5:2023 – Autorisierung auf fehlerhafter Funktionsebene
13
API6:2023 – Uneingeschränkter Zugriff auf sensible Geschäftsabläufe
14
API7:2023 – Serverseitige Anforderungsfälschung
16
API8:2023–Sicherheitsfehlkonfiguration
18
API9:2023 – Unsachgemäße Bestandsverwaltung
19
API10:2023 – Unsichere Nutzung von APIs
21
Die API Security Top-10 reichen nicht aus!
23
Abschluss
23
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
2/23
Da Unternehmen Cloud-native Infrastrukturen und DevOp-Methoden eingeführt haben, web Anwendungsprogrammierschnittstellen (APIs) haben sich stark verbreitet. Zu den beliebtesten öffentlichen APIs gehören solche, die Entwicklern den Zugriff auf die Google-Suche, das Scraping von TikTok-Daten, das Tracking von Fahrzeugen, das Sammeln von Sportergebnissen und das Erfassen von Daten zu Bilddownloads von beliebten Websites ermöglichen.1 Im Jahr 2023 machte der API-bezogene Datenverkehr 58 Prozent des gesamten dynamischen – also nicht zwischenspeicherbaren – Datenverkehrs aus, gegenüber 54 Prozent Ende 2021.2
APIs sind mittlerweile auch für Unternehmensanwendungen zur Kommunikation und Integration untereinander geworden. Unternehmen nutzen etwa zwei Drittel ihrer APIs (64 %), um ihre Anwendungen mit Partnern zu verbinden, während etwa die Hälfte (51 %) als Zugangspunkte zu Microservices dienen. Insgesamt nutzen mehr als drei Viertel der Unternehmen durchschnittlich mindestens 25 APIs pro Anwendung.
Die Einführung API-basierter Anwendungsinfrastrukturen dürfte nicht überraschen: Unternehmen, die APIs nutzen, um externe Entwickler zu gewinnen und Ökosysteme zu schaffen, verzeichnen ein erhöhtes Wachstum. Diese „invertierten Unternehmen“ – so genannt, weil sie die traditionellen Konzepte der Barrierenbildung um Technologien umkehren und offenen Zugang zu bestimmten Funktionen und Daten ermöglichen – wuchsen laut einer Studie von Forschern der Chapman University und der Boston University aus dem Jahr 13 im Vergleich zu Unternehmen ohne APIs innerhalb von zwei Jahren um fast 39 Prozent und innerhalb von 16 Jahren um 2022 Prozent.
Mit der Einführung von Microservices, Containerisierung und APIs gehen jedoch verschiedene Risiken einher, wie unsichere Softwarekomponenten, mangelhafte Geschäftslogik und mangelhafte Datensicherheit. Neun von zehn Unternehmen (92 %) waren bereits von mindestens einem Sicherheitsvorfall im Zusammenhang mit unsicheren APIs betroffen.5 Große Unternehmen verfügen typischerweise über Tausende von APIs, und Angriffe auf diese Systeme machen etwa 20 Prozent der Sicherheitsvorfälle aus. Kleinere Unternehmen hingegen verfügen über Hunderte von APIs, deren kleinere Angriffsfläche fünf Prozent der Sicherheitsvorfälle ausmacht.6 Die jährlichen Verluste durch Sicherheitsverletzungen aufgrund von API-Schwachstellen belaufen sich weltweit auf über 40 Milliarden US-Dollar, so eine Schätzung von Marsh McLennan.7
1 Arellano, Kelly. Die 50 beliebtesten APIs. RapidAPI Blog. RapidAPI. Web Seite. 16. März 2023.
2 Tremante, Michael, et al. Anwendungssicherheitsbericht: Q2 2023. Cloudflare Blog. Cloudflare. Blogbeitrag. 21. August 2023.
3 Marks, Melinda. Sicherung der API-Angriffsfläche. Enterprise Strategy Group. Gesponsert von Palo Alto Networks. PDF-Bericht, S. 10. 23. Mai 2023.
4 Benzell, Seth G., et al. Wie APIs Wachstum schaffen, indem sie das Unternehmen umkehren. Social Science Research Network. Forschungsarbeit. Überarbeitet: 30. Dezember 2022.
5 Sicherung der API-Angriffsfläche. Enterprise Strategy Group, S. 14. 6 Lemos, Robert. API-Sicherheitsverluste belaufen sich auf Milliarden, aber die Sache ist kompliziert. Dunkle Lektüre.
Nachrichtenartikel. 30. Juni 2022. 7 Marsh McLennan. Die Kosten von API-Unsicherheit quantifizieren. Gesponsert von Imperva.
PDF-Bericht. 22. Juni 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
3/23
Die API Security Top-2023-Liste 10 hebt die zehn häufigsten und schwerwiegendsten Sicherheitsrisiken hervor, die bei der Entwicklung von Anwendungen entstehen, die APIs offenlegen oder verwenden.
Das Problem ist so ernst, dass sich die US-amerikanische National Security Agency (NSA) mit dem Australian Cyber Security Centre (ACSC) und der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) zusammengeschlossen hat, um Leitlinien zu API-Sicherheitsproblemen anzubieten, insbesondere zu den häufigsten, den sogenannten unsicheren direkten Objektreferenz-Schwachstellen (IDOR).8
Vor dem Hintergrund wachsender Sicherheitsbedenken überrascht es nicht, dass das Open Worldwide Application Security Project (OWASP) seine API Security Top-10-Liste aktualisiert hat. Die aktualisierte Liste aus dem Jahr 2019 hebt die zehn häufigsten und schwerwiegendsten Sicherheitsrisiken bei der Entwicklung von Anwendungen hervor, die APIs nutzen. Probleme wie „Broken Object-Level Authorization“, eine Obermenge, die auch IDOR-Schwachstellen umfasst, bleiben gegenüber der vorherigen Liste unverändert. Neue Kategorien – oder neu geordnete Kategorien – heben jedoch bisher übersehene Probleme hervor, wie z. B. „Server-Side Request Forgery“ (API2023:10) und „Unrestricted Access to Sensitive Business Flows“ (API7:2023).
“By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this, APIs have increasingly become a target for attackers,” the OWASP group stated in its announcement.9 “Without secure APIs, rapid innovation would be impossible.”
8 Neue Cybersicherheitsempfehlungen warnen vor Web Anwendungsschwachstellen. Nationale Sicherheitsagentur. Pressemitteilung. 27. Juli 2023.
9 Open Worldwide Application Security Project. OWASP API Security Top 10: Weiter. OWASP.org. Web Seite. 3. Juli 2023.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
4/23
Spickzettel zur API-Sicherheit
OWASP Top 10 Kategorie 1. Beschädigte Autorisierung auf Objektebene 2. Beschädigte Authentifizierung 3. Beschädigte Autorisierung auf Objekteigenschaftsebene 4. Uneingeschränkter Ressourcenverbrauch 5. Beschädigte Autorisierung auf Funktionsebene 6. Uneingeschränkter Zugriff auf sensible Geschäftsabläufe 7. Serverseitige Anforderungsfälschung 8. Sicherheitsfehlkonfiguration 9. Unsachgemäße Bestandsverwaltung 10. Unsicherer Verbrauch von APIs
Cybersicherheitslösung SAST SAST, DAST SAST, DAST SAST, DAST, Secure API Manager SAST DAST DAST SAST, DAST Secure API Manager SCA, SAST
Definitionen
API-Endpunkt – Der Kommunikationspunkt zwischen zwei Systemen, normalerweise ein URL eines Containers oder Servers, auf dem ein Microservice läuft. Mithilfe eines URL, kann eine Anwendung oder ein Entwickler Informationen vom Server anfordern oder eine Aktion auf dem API-Server oder Microservice ausführen.
API-bezogener Datenverkehr – Internetdatenverkehr, der aus einer HTTP- oder HTTPS-Anfrage besteht und einen Antwortinhalt im XML- oder JSON-Format aufweist, was darauf hinweist, dass Daten an eine Anwendung übergeben werden, normalerweise über SOAP, WSDL, eine REST-API oder gRPC (siehe unten).
Dynamic Application Security Testing (DAST)–Der Prozess der Analyse einer Anwendung oder eines API-Servers mithilfe der Schnittstelle, sei es die Benutzeroberfläche für eine Anwendung, eine web Frontend für ein web Anwendung oder URLs für API-Endpunkte. Bei diesem Ansatz handelt es sich um eine Art Black-Box-Test. Dabei wird eine Anwendung von außen nach innen bewertet, indem sie auf die gleiche Weise wie ein Angreifer angegriffen wird, in der Regel ohne Kenntnis der internen Prozesse.
Statisches Testen der Anwendungssicherheit (SAST) – Ein Ansatz zur Anwendungssicherheit, der den Quell-, Binär- oder Bytecode auf bekannte Fehlermuster oder Schwachstellen prüft. SAST, auch als White-Box-Test bezeichnet, verwendet einen „Inside-Out“-Ansatz, der potenzielle Schwachstellen und Fehler identifiziert, die von einem externen Angreifer ausgenutzt werden können. Leichtgewichtige statische Tools können Entwicklern in ihrer IDE Echtzeit-Feedback liefern.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
5/23
Defekte Autorisierung auf Objektebene ist ein weit verbreitetes und leicht auszunutzendes Problem in web Anwendungen, da API-Aufrufe Statusinformationen enthalten. Anwendungen sind anfällig, wenn sie einem Benutzer Aktionen durch die Angabe einer Kennung in einer API ermöglichen, ohne zu prüfen, ob er für diese Aktionen berechtigt ist.
SOAP/WSDL – Ein XML-basiertes Protokoll zum Erstellen Web APIs. SOAP ist das Protokoll selbst und WSDL (Web Service Definition Language (kurz: SDL) ist das Format zur formalen Beschreibung von Diensten. Aufgrund des hohen Overheads ist dieser API-Stil bei Neuentwicklungen unbeliebt geworden.
REST–A Web API-Stil, bei dem Nachrichten direkt über HTTP ausgetauscht werden, unter Verwendung der Semantik von HTTP URLs und Verben, ohne einen zusätzlichen „Umschlag“ zu verwenden. Der Inhalt wird normalerweise als JSON kodiert, in einigen Fällen jedoch auch als XML.
GraphQL – Eine Abfragesprache für APIs (mit Anfragen und Antworten in JSON) sowie serverseitige Laufzeitumgebungen zur Ausführung dieser Abfragen. Sie ermöglicht es Clients, die benötigte Datenstruktur zu definieren und diese dann in diesem Format vom Server zu empfangen.
gRPC – Ein API-Protokoll, das leistungsstärker ist als REST. Es nutzt HTTP/2 und die Leistungsvorteiletages, das über HTTP/1.1 angeboten wird. Das Format der einzelnen Nachrichten ist in der Regel binär und basiert auf ProtoBuf, was wiederum Leistungsvorteile bietet.tages über REST und SOAP.
API-Sicherheit Top 2023 10
Analoger API-Sicherheitseintrag 2019
API1:2023 – Autorisierung auf Ebene defekter Objekte
API1:2019 – Autorisierung auf Ebene defekter Objekte
API2:2023 – Defekte Authentifizierung
API2:2019 – Fehlerhafte Benutzerauthentifizierung
API3:2023–Autorisierung auf Eigenschaftsebene für defekte Objekte
API3:2019 – Übermäßige Datenfreigabe, API6:2019 – Massenzuweisung
API4:2023 – Uneingeschränkter Ressourcenverbrauch
API4:2019 – Mangel an Ressourcen und Ratenbegrenzung
API5:2023 – Autorisierung auf fehlerhafter Funktionsebene
API5:2019 – Autorisierung auf fehlerhafter Funktionsebene
API6:2023 – Uneingeschränkter Zugriff auf sensible Geschäftsabläufe
API7:2023 – Serverseitige Anforderungsfälschung
API8:2023–Sicherheitsfehlkonfiguration API7:2019–Sicherheitsfehlkonfiguration
API9:2023 – Unsachgemäße Bestandsverwaltung
API9:2019 – Unsachgemäße Vermögensverwaltung
API10:2023 – Unsichere Nutzung von APIs
API8:2019–Injektion, API10:2019–Unzureichende Protokollierung und Überwachung
Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
6/23
Entwickler und Anwendungssicherheitsteams müssen außerdem Funktionen zur Überprüfung der Benutzeridentität durch Authentifizierung ordnungsgemäß implementieren.
API1:2023 – Autorisierung auf Ebene defekter Objekte
Was ist das?
APIs ermöglichen den Zugriff auf Dienste und Daten über standardisierte web Anfragen. Unternehmen setzen ihre Infrastruktur und Daten einem unsicheren Direktzugriff aus, wenn diese nicht ausreichend geschützt sind oder die Autorisierungskontrollen schlecht implementiert oder gar nicht vorhanden sind. Eine fehlerhafte Objektebenenautorisierung – auch als Insecure Direct Object Reference (IDOR) bezeichnet – kann verschiedene Risiken bergen, von der Datenoffenlegung bis hin zur vollständigen Kontoübernahme.
Was macht eine Anwendung anfällig?
Dies ist ein weit verbreitetes und leicht auszunutzendes Problem in web Anwendungen. Anwendungen sind anfällig, wenn sie einem Benutzer durch die Angabe einer Kennung in einer API Aktionen ermöglichen, ohne zu prüfen, ob er zur Durchführung dieser Aktionen berechtigt ist.
In einer ExampWie von OWASP detailliert beschrieben, könnte eine Plattform für Online-Shops den Zugriff auf Shop-Daten durch einen einfachen Anruf ermöglichen:
/shops/{shopName}/revenue _ data.json
Dies ist unsicher, da jeder Benutzer den Shop-Namen durch den Namen des Geschäfts eines anderen Benutzers ersetzen und so Zugriff auf Daten erhalten kann, die ihm nicht zustehen.
Angriff examples
Im Jahr 2021 stellte ein Sicherheitsforscher fest, dass die webAnwendungs- und Back-End-Server, die Daten an Peloton-Heimtrainer lieferten, verfügten über mehrere API-Endpunkte, über die nicht authentifizierte Benutzer auf private Daten zugreifen konnten. Im Februar 2021 implementierte Peloton eine Teillösung für das Problem, die den API-Zugriff auf authentifizierte Benutzer beschränkte, diesen Benutzern aber weiterhin den Zugriff auf alle privaten Daten anderer Mitglieder ermöglichte. Eine vollständige Lösung erfolgte im Mai 2021.10.
Wie kann man dies als Entwickler verhindern?
Entwickler verhindern unsicheren Zugriff auf Objekte, indem sie strenge Kontrollen durchsetzen, unvorhersehbare Benutzerkennungen zuweisen, um die Aufzählung von Konten zu verhindern, und die Autorisierung auf Objektebene für jede Funktion prüfen, die auf eine Datenquelle zugreift. Entwickler sollten solche Prüfungen kapseln, insbesondere wenn sie auf Benutzereingaben basieren, um die Möglichkeit auszuschließen, dass unbeabsichtigte Fehler die Sicherheit gefährden. Anwendungssicherheits- und Betriebsexperten sollten für jede Anforderung von Backend-Daten Autorisierungsprüfungen verlangen.
Wie kann OpenText helfen?
OpenTextTM Static Application Security Testing (SAST) und OpenTextTM Dynamic Application Security Testing (DAST) können eine breite Palette von Schwachstellen in der Kategorie Insecure Direct Object Reference (IDOR) erkennen. IDOR kann Schwachstellen wie Directory Traversal umfassen, File Hochladen und File Inklusion. Im Allgemeinen umfasst IDOR auch Klassen von Schwachstellen, bei denen Kennungen
10 Masters, Jan. Tour de Peloton: Offengelegte Benutzerdaten. Blog von Pen Test Partners. Pen Test Partners. Web Seite. 5. Mai 2021.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
7/23
Entwickler und Anwendungssicherheitsteams müssen außerdem Funktionen zur Überprüfung der Benutzeridentität durch Authentifizierung ordnungsgemäß implementieren.
kann geändert werden über URL, Body- oder Header-Manipulation. Das System warnt Entwickler, wenn der Benutzer den Primärschlüssel in der API-Anfrage für eine Datenbank oder einen Speichercontainer direkt auswählen kann. Dieses Problem führt häufig zu dieser Art von Sicherheitslücken. Das System warnt auch, wenn eine erwartete Autorisierungsprüfung fehlt.
API2:2023 – Defekte Authentifizierung
Was ist das?
Autorisierungsprüfungen beschränken den Datenzugriff auf bestimmte Rollen oder Benutzer. Diese Einschränkungen reichen jedoch nicht aus, um Systeme, Daten und Dienste zu schützen. Entwickler und Anwendungssicherheitsteams müssen außerdem Funktionen zur Überprüfung der Benutzeridentität durch Authentifizierung ordnungsgemäß implementieren. Trotz der kritischen Natur der Authentifizierung werden die Komponenten oft schlecht implementiert oder falsch verwendet – die Hauptursachen für eine fehlerhafte Benutzerauthentifizierung. Eine fehlerhafte Benutzerauthentifizierung ermöglicht es Angreifern, die Identität anderer Benutzer vorübergehend oder dauerhaft anzunehmen, indem sie unsichere Authentifizierungstoken ausnutzen oder Implementierungsfehler ausnutzen.
Was macht eine Anwendung anfällig?
Dieses häufige und leicht auszunutzende Problem entsteht, weil die Authentifizierung ein komplexer, verwirrender und per Definition öffentlich zugänglicher Prozess ist. Entwicklerfehler und Fehlkonfigurationen von Anwendungen können dazu führen, dass notwendige Prüfungen fehlen, sodass Angreifer die Authentifizierung umgehen können. Entwickler, die die Authentifizierung für einen bestimmten Endpunkt nicht implementieren oder schwache Authentifizierungsmechanismen zulassen, setzen Anwendungen einer Vielzahl von Angriffen aus, wie z. B. Credential Stuffing, Token Replay oder Passwort-Sniffing.
Angriff examples
Zwischen Februar und Juni 2023 zielten Credential-Stuffing-Angriffe auf den Bekleidungshändler Hot Topic ab. Hot Topic informierte seine Kunden über die Kompromittierung einer unbekannten Anzahl von Konten. Mithilfe von Anmeldeinformationen aus unbekannten Quellen konnten die Angreifer auf sensible persönliche Daten wie Namen, E-Mail-Adressen, Bestellhistorien, Telefonnummern sowie Geburtsdaten zugreifen.
Im Februar 2022 wurden aufgrund eines falsch konfigurierten Cloud-Speichers 1 GB sensibler Daten des E-Mail-Marketing-Dienstes Beetle Eye ohne Passwortschutz und Verschlüsselung gespeichert. Die Daten umfassten Kontaktdaten und tourismusbezogene Informationen, die von verschiedenen Tourismusagenturen und US-Bundesstaaten gesammelt wurden.12 Falsch konfigurierte Authentifizierungsmechanismen gelten als Variante der Kategorie „Beschädigte Benutzerauthentifizierung“.
Wie kann man dies als Entwickler verhindern?
11 Toulas, Bill. Die Einzelhandelskette Hot Topic gibt eine Welle von Credential-Stuffing-Angriffen bekannt. BleepingComputer. Nachrichtenartikel. 1. August 2023.
12 Nair, Prajeet. Daten von 7 Millionen Menschen über US-Marketingplattform offengelegt. Datenleck heute. ISMG-Netzwerk. 11. Februar 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
8/23
Standardisierung ist Ihr Vorteil bei der Authentifizierung. DevSecOps-Teams sollten eine oder eine begrenzte Anzahl von Authentifizierungsmethoden für Anwendungen erstellen und sicherstellen, dass Entwickler die Mechanismen einheitlich für alle Microservices und APIs implementieren.
Standardisierung ist Ihr Vorteil bei der Authentifizierung. DevSecOps-Teams sollten eine oder eine begrenzte Anzahl von Authentifizierungsmethoden für Anwendungen erstellen und sicherstellen, dass Entwickler die Mechanismen einheitlich für alle Microservices und APIs implementieren. Jede Authentifizierungsimplementierung sollteviewIm Rahmen des OWASP Application Security Verification Standard (ASVS), aktuell in der Version 4,13, wird die korrekte Implementierung und die zugehörigen Sicherheitskontrollen sichergestellt. Jede Abweichung vom Standard – insbesondere die absichtliche Offenlegung nicht authentifizierter Endpunkte – sollte vom Sicherheitsteam geprüft und nur zur Erfüllung strenger Geschäftsanforderungen zugelassen werden.
Wie kann OpenText helfen?
OAuth und JWT sind zwei der gängigsten Authentifizierungsarten für die Implementierung von APIs. OpenText Dynamic Application Security Testing prüft Anwendungen auf schwache Implementierungen beider Standards sowie auf Fehlkonfigurationen und anfällige Muster wie CSRF und Session Fixation, die bei benutzerdefinierten Authentifizierungsimplementierungen auftreten. Das Scannen mit dem Dynamic Application Security Tool (DAST) von OpenText eignet sich hervorragend zum Aufspüren von Authentifizierungsschwachstellen, insbesondere in APIs.
OpenText Static Application Security Testing ermöglicht zudem eine breite Palette von Prüfungen auf unzureichende Authentifizierung. Das statische Analysetool erkennt allgemeine Probleme – wie etwa den Verlust von Anmeldeinformationen – sowie API-spezifische Probleme wie fehlende Schutzansprüche in JWT-Token oder Ansprüche in JWT-Headern.
API3:2023–Autorisierung auf Eigenschaftsebene für defekte Objekte
Was ist das?
„Beschädigte Autorisierung auf Objekteigenschaftsebene“ ist eine neue Kategorie in der OWASP-Liste 2023, die zwei Kategorien aus der vorherigen Liste kombiniert: „Excessive Data Exposure“ (API3:2019) und „Mass Assignment“ (API6:2019). Das Problem entsteht durch die fehlende oder fehlerhafte Validierung der Benutzerautorisierung auf Objekteigenschaftsebene. API-Endpunkte sollten überprüfen, ob jeder Benutzer für jede Eigenschaft, auf die er zugreifen oder die er ändern möchte, die Berechtigung besitzt. Die Ausnutzung dieses Problems kann zur Offenlegung von Informationen oder zur Manipulation von Daten durch Unbefugte führen.
Was macht eine Anwendung anfällig?
Das häufige und leicht auszunutzende Problem tritt auf, wenn ein Benutzer möglicherweise auf bestimmte Eigenschaften eines bestimmten Objekts zugreifen darf, z. B. auf die Zimmerreservierung in einer Reise-App, aber nicht auf andere, z. B. den Zimmerpreis. Wenn der Benutzer über eine API auf die Eigenschaften eines Objekts zugreift, sollte die Anwendung Folgendes überprüfen:
· Sollte Zugriff auf die spezifische Eigenschaft des Objekts erhalten können
13 OWASP Application Security Verification Standard. OWASP. GitHub-Seite. Letzter Zugriff: 17. November 2023.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
9/23
„Broken Object Property Level Authorization“ ist eine neue Kategorie in der OWASP-Liste 2023, die zwei Kategorien aus der vorherigen Liste kombiniert: „Excessive Data Exposure“ (API3:2019) und „Mass Assignment“ (API6:2019).
OpenTextTM Static Application Security Testing hilft durch Datenflussanalyse, übermäßige Datenexposition und Massenzuweisung zu verhindern. Das System hebt zahlreiche Quellen privater Daten hervor, beispielsweise solche, die auf Variablennamen oder bestimmten API-Aufrufen basieren, und identifiziert Objekte, die eine Massenzuweisung ermöglichen.
(Verstöße wurden früher als übermäßige Datenexposition bezeichnet) und/oder
· Darf die spezifische Eigenschaft des Objekts ändern (einige Anwendungen überprüfen dies nicht, weil sie ein Framework verwenden, um automatisch abzubilden web Anforderungsparameter zu Objektfeldern, ein Problem, das als Massenzuweisung bekannt ist).
In einem OWASP-ExampBeispielsweise ermöglicht eine Online-Videoplattform einem Benutzer, die Beschreibung eines Videos zu ändern, sogar eines blockierten Videos, sollte dem Benutzer jedoch nicht erlauben, die Eigenschaft „blockiert“ zu ändern.
PUT /api/video/update _ video
{
„Beschreibung“: „Ein lustiges Video über Katzen“,
„blockiert“: falsch
}
Angriff examples
Im Januar 2022 entdeckte ein Bug-Bounty-Programm eine Schwachstelle bei Twitter, die es Nutzern ermöglichte, eine E-Mail-Adresse oder Telefonnummer an das Twitter-System zu übermitteln, das daraufhin den zugehörigen Kontonamen zurückgab.14 Ein unbekannter Angreifer nutzte die Schwachstelle, um eine Liste mit Millionen von Nutzerkonten zu erstellen, die mit Telefonnummern und E-Mail-Adressen verknüpft waren. Indem Twitter jedem die Verknüpfung zweier Eigenschaften ermöglichte, ermöglichte es unbeabsichtigt eine genauere Identifizierung pseudonymer Nutzer.
Wie kann man dies als Entwickler verhindern?
Entwickler sollten stets geeignete Kontrollen für den Zugriff auf oder die Änderung bestimmter Objekteigenschaften implementieren. Anstatt eine allgemeine Datenstruktur mit jeder Eigenschaft zurückzugeben – was häufig bei generischen Methoden wie to_json() und to_string() der Fall ist – sollten Programmierer sehr genau festlegen, welche Informationen sie zurückgeben. Als zusätzliche Sicherheitsmaßnahme sollten Anwendungen eine schemabasierte Antwortvalidierung implementieren, die Sicherheitskontrollen für alle von API-Methoden zurückgegebenen Daten durchsetzt. Der Zugriff sollte nach dem Prinzip der geringsten Privilegien erfolgen und nur dann gewährt werden, wenn dies unbedingt erforderlich ist.
Wie kann OpenText helfen?
OpenTextTM Static Application Security Testing hilft durch Datenflussanalyse, übermäßige Datenexposition und Massenzuweisung zu verhindern. Das System hebt zahlreiche Quellen privater Daten hervor, beispielsweise solche, die auf Variablennamen oder bestimmten API-Aufrufen basieren, und identifiziert Objekte, die eine Massenzuweisung ermöglichen. Benutzer können auch eigene Quellen definieren, Daten durch das Programm verfolgen und den Entwickler oder Betreiber auf das Risiko aufmerksam machen, wenn sie an einer ungeeigneten Stelle landen.
14 Ein Vorfall, der einige Konten und private Informationen auf Twitter betrifft. Twitter-Datenschutzcenter. Twitter. Web Seite. 5. August 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
10/23
Anwendungen, die die zur Erfüllung einer Anfrage zugewiesenen Ressourcen nicht begrenzen, können anfällig sein. Dazu gehören auch solche, die den zuweisbaren Speicher, die Anzahl der fileZugegriffen wird auf s oder Prozesse oder die zulässige Anforderungsrate, neben anderen Attributen.
Darüber hinaus verfügt OpenText SAST über Kenntnisse der wichtigsten JSON- und XML-Serialisierungs- und Deserialisierungsmechanismen. Dadurch kann das Tool Code erkennen, der die Domain Transfer Objects (DTOs) nicht ordnungsgemäß deserialisiert, was eine Massenzuweisung ihrer Attribute ermöglichen könnte. Einige Fälle von Informationsoffenlegung und Massenzuweisung können auch mit OpenText Dynamic Application Security Testing erkannt werden. Schließlich können Gegenmaßnahmen durch das Hinzufügen von Regeln zu den web Anwendungsfirewall (WAF).
API4:2023 – Uneingeschränkter Ressourcenverbrauch
Was ist das?
APIs stellen viele nützliche Geschäftsfunktionen bereit. Dazu nutzen sie Rechenressourcen wie Datenbankserver oder greifen über Betriebstechnologie auf physische Komponenten zu. Da Systeme nur über begrenzte Ressourcen verfügen, um auf API-Aufrufe zu reagieren, können Angreifer Anfragen so gestalten, dass Szenarien entstehen, die zu Ressourcenerschöpfung, Denial-of-Service-Angriffen oder erhöhten Geschäftskosten führen. In vielen Fällen können Angreifer API-Anfragen senden, die erhebliche Ressourcen binden, den Rechner oder die Bandbreite überlasten und einen Denial-of-Service-Angriff auslösen. Durch wiederholtes Senden von Anfragen von verschiedenen IP-Adressen oder Cloud-Instanzen können Angreifer Abwehrmaßnahmen umgehen, die verdächtige Nutzungsspitzen erkennen.
Was macht eine Anwendung anfällig?
API requests trigger responses. Whether those responses involve accessing a database, performing I/O, running calculations, or (increasingly) generating the output from a machine-learning model, APIs use computing, network, and memory resources. An attacker can send API requests to an endpoint as part of a denial-of-service (DoS) attack that, rather than overwhelm bandwidth–the goal of a volumetric DoS attack–instead exhaust CPU, memory, and cloud resources. Applications that do not limit the resources assigned to satisfy a request can be vulnerable, including those that fail to restrict allocable memory, number of fileZugegriffen wird auf s oder Prozesse oder die zulässige Anforderungsrate, neben anderen Attributen.
Für die Serververarbeitungs-APIs müssen Beschränkungen gelten, um eine übermäßige Speicher- und Arbeitslastzuweisung, übermäßige Anforderungen für API-ausgelöste Vorgänge oder überhöhte Gebühren für Dienste von Drittanbietern ohne Ausgabenbeschränkungen zu verhindern.
A common attack is to modify the arguments passed to the API endpoint, such as increasing the size of the response and requesting millions of database entries, rather than, say, the first ten:
/api/Benutzer?Seite=1&Größe=1000000
Wenn der Angreifer außerdem auf einen Backend-Dienst zugreifen kann, der Gebühren für die Nutzung erhebt, können Angriffe auf Ressourcenverbrauch genutzt werden, um Kosten für den Anwendungsbesitzer zu verursachen. Ein weiteres Beispiel für OWASPample weist auf eine Funktion zum Zurücksetzen des Passworts hin, die zur Identitätsüberprüfung eine SMS-Textnachricht verwendet und tausende Male aufgerufen werden könnte, um die Kosten für das Opfer zu erhöhen.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
11/23
Filterung am Rand des Netzwerks mithilfe von Content Delivery Networks (CDNs) gepaart mit web Anwendungsfirewalls (WAFs) können Datenverkehrsfluten reduzieren und gleichzeitig die Auswirkungen auf einzelne Benutzer minimieren.
POST /sms/send_reset_pass_code
Host: willyo.net {
„Telefonnummer“: „6501113434“ }
Angriff examples
Da Angriffe auf Ressourcenverbrauch oft mit Leistungs- und Verfügbarkeitsproblemen in Zusammenhang gebracht werden, behandeln betroffene Unternehmen sie eher als Teil ihrer Geschäftskosten als als meldepflichtige Vorfälle, was die Transparenz der Bedrohung verringert. Im Jahr 2022 gingen Distributed-Denial-of-Service-Angriffe (DDoS) auf Anwendungsebene, eine Obergruppe der Angriffe auf API-Ressourcenverbrauch, als Anteil aller Angriffe zurück, doch im vierten Quartal 4 wurden immer noch 2022 % mehr Angriffe registriert als im Vorjahresquartal.79
Bei einem Angriff aus dem Jahr 2015 entdeckte ein Entwickler einen Android-Client, der wiederholt Kontakt mit dem Server seiner Website aufnahm. Web API mit zufällig generierten API-Schlüsseln, was zu einem Denial-of-Service-Angriff führte. Der Entwickler vermutete, dass eine auf Android-Geräten installierte Schadanwendung versuchte, den 64-Bit-API-Schlüssel zu erraten.16
Wie kann man dies als Entwickler verhindern?
Durch den Einsatz von Ratenbegrenzungen und Schwellenwerten lassen sich die meisten Angriffe auf Ressourcenverbrauch abwehren. Allerdings kann auch legitimer Datenverkehr durch schlecht konstruierte Abwehrmechanismen beeinträchtigt werden. Spezifische Grenzwerte sollten für Folgendes festgelegt werden:
· Speicherzuweisung
· Prozesse
· Cloud-Instanzen
· Hochgeladen file Deskriptoren und file Größe
· Datensätze zurückgegeben
· Anzahl der bezahlten Transaktionen zu Diensten Dritter
· Alle eingehenden Parameter (zB Stringlängen, Arraylängen usw.)
· Anzahl der API-Interaktionen pro Client innerhalb eines bestimmten Zeitfensters
Filterung am Rand des Netzwerks mithilfe von Content Delivery Networks (CDNs) gepaart mit web Anwendungs-Firewalls (WAFs) können Datenverkehrsfluten reduzieren und gleichzeitig die Auswirkungen auf einzelne Benutzer minimieren. Anwendungsbereitstellungsplattformen ermöglichen eine einfache Filterung, einschließlich der Begrenzung von Speicher, CPUs und Prozessen.
15 Yoachimik, Omer. Cloudflare DDoS-Bedrohungsbericht für das 2022. Quartal 4. Cloudflare Blog. Web Seite. 10. Januar 2023.
16 Wie man Hack/DOS-Angriffe auf web API.StackOverflow. Web Seite. 15. September 2015.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
12/23
OpenText Dynamic Application Security Testing kann Server und API-Funktionen auf Anfälligkeit für Denial-of-Service-Angriffe prüfen, ohne den Dienst zu beeinträchtigen. Darüber hinaus kann allein durch die Ausführung eines DAST-Scans eine Umgebung einem Stresstest unterzogen werden, um potenzielle Schwachstellen im Ressourcenverbrauch aufzuzeigen.
Wie kann OpenText helfen?
Mit OpenText SAST und OpenText Dynamic Application Security Testing können DevSecOps-Teams ihren Code und ihre Infrastruktur auf Widerstandsfähigkeit gegen Ressourcenerschöpfungsangriffe testen. OpenText SAST erkennt viele Bereiche, in denen ein Angreifer die Anwendungslogik missbrauchen könnte, um einen extremen Ressourcenverbrauch zu verursachen.
Sicherheit auf Codeebene reicht nicht aus, um dieses Problem in der Anwendung zu beheben. Ressourcenerschöpfung und Ratenbegrenzung sind spezifische Teilaspekte von Denial-of-Service-Angriffen, die zur Laufzeit abgeschwächt werden sollten. OpenText Dynamic Application Security Testing kann Server und API-Funktionen auf Anfälligkeit für Denial-of-Service-Angriffe testen, ohne den Dienst zu beeinträchtigen. Darüber hinaus kann allein durch die Durchführung eines DAST-Scans eine Umgebung einem Stresstest unterzogen werden, der potenzielle Schwachstellen im Ressourcenverbrauch aufzeigt.
API5:2023 – Autorisierung auf fehlerhafter Funktionsebene
Was ist das?
Moderne Anwendungen verfügen über viele verschiedene Funktionen, die auf Daten zugreifen, diese erstellen, bearbeiten, löschen und verwalten. Nicht jeder Anwendungsbenutzer benötigt Zugriff auf alle Funktionen oder Daten, und nicht jeder sollte dies nach dem Prinzip der geringsten Privilegien auch erhalten. Jeder API-Endpunkt hat eine Zielgruppe, die anonyme, reguläre, nicht privilegierte und privilegierte Benutzer umfassen kann. Verwaltungs- und Managementfunktionen sollten eine privilegierte Autorisierung erfordern, sind aber manchmal über legitime API-Aufrufe von nicht autorisierten Benutzern zugänglich – der Ursprung der „Broken Function Level Authorization“. Da unterschiedliche Hierarchien, Gruppen und Rollen die Zugriffskontrollen komplex machen, unterliegen Anwendungsfunktionen möglicherweise keinen angemessenen Einschränkungen hinsichtlich der Aufrufberechtigung.
Was macht eine Anwendung anfällig?
Anwendungen, die bestimmte Funktionen zur Durchführung administrativer Aufgaben zulassen, dürfen den Zugriff auf diese Funktionen nicht auf sichere Weise einschränken. APIs, die direkt auf solche Funktionen verweisen, machen diese Schwachstellen anfällig für Ausnutzungen. Funktionen, die den Authentifizierungs- und Autorisierungsmechanismus der Anwendung nicht nutzen, sollten als potenzielle Sicherheitslücken betrachtet werden.
In einer ExampWie von OWASP zitiert, erhält ein Angreifer Zugriff auf die API-Anfragen zum Hinzufügen eines eingeladenen Benutzers zu einer neuen mobilen Anwendung. Dabei stellt er fest, dass die Einladung Informationen zur Rolle des Eingeladenen enthält. Der Angreifer nutzt diese Schwachstelle aus und versendet eine neue Einladung:
POST /api/einladungen/neu
{
„E-Mail“: „attacker@somehost.com“,
„Rolle“:“Administrator“
} Dadurch erhalten sie Administratorrechte auf dem System.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
13/23
DevSecOps-Teams sollten einen Standardansatz für Autorisierung und Authentifizierung entwickeln, der den Zugriff auf Anfragen standardmäßig verhindert und die Vorgabe „Alles verweigern“ erzwingt.
Anwendungssteuerung und Logikflüsse bilden das Herzstück jedes Online-Unternehmens. Da Unternehmen immer mehr ihrer Geschäftstätigkeiten in die Cloud verlagern, können diese Flüsse offengelegt und ausgenutzt werden. Dieser übermäßige Zugriff kann dem Unternehmen schaden.
Angriff examples
Im Jahr 2022 informierte das texanische Versicherungsministerium die Öffentlichkeit darüber, dass Informationen von fast zwei Millionen Texanern über einen Teil des Antrags auf Arbeitnehmerentschädigung offengelegt worden waren, der es der Öffentlichkeit versehentlich ermöglichte, auf geschützte Daten zuzugreifen.17 Bei einem zweiten Vorfall im Jahr 2022 räumte das australische Telekommunikationsunternehmen Optus ein, dass persönliche Daten und Kontoinformationen von bis zu 10 Millionen Australiern über eine API offengelegt worden waren, die keine Authentifizierung oder Autorisierung erforderte. Während Optus den Angriff als „raffiniert“ bezeichnete, bezeichnete ihn ein mit den Details vertrauter Sicherheitsforscher als „trivial“.18
Wie kann man dies als Entwickler verhindern?
DevSecOps-Teams sollten einen Standardansatz für Authentifizierung und Autorisierung entwickeln, der den Zugriff auf Anfragen standardmäßig verhindert und die Vorgabe „Alles verweigern“ erzwingt. Ausgehend von dieser Vorgabe sollte bei der Zugriffsregelung für Rollen/Gruppen/Benutzer stets das Prinzip der geringsten Privilegien angewendet werden. Entwickler sollten sicherstellen, dass Authentifizierung und Autorisierung für alle relevanten HTTP-Verben/-Methoden (z. B. POST, GET, PUT, PATCH, DELETE) für jeden API-Endpunkt vorhanden sind. Irrelevante Verben sollten nicht zugelassen werden. Darüber hinaus sollten Entwickler eine Basisklasse für administrativen Zugriff und Verwaltung implementieren und dabei Klassenvererbung nutzen, um sicherzustellen, dass Autorisierungskontrollen die Rolle des Benutzers prüfen, bevor Zugriff gewährt wird. Alle kritischen Verwaltungsfunktionen sollten den Autorisierungsmechanismus nutzen, um eine Rechteausweitung zu verhindern.
Wie kann OpenText helfen?
Durch die Kombination der statischen Code- und API-Analysefunktionen von OpenTextTM Static Application Security Testing mit den Laufzeitprüfungen der OpenText Dynamic Application Security Testing (DAST)-Suite können DevSecOps-Teams ihre Anwendung auf Autorisierungsprobleme auf Funktionsebene überprüfen und den Produktionscode vor der Bereitstellung kontinuierlich auf Sicherheitslücken testen. Um Probleme mit der Autorisierung defekter Objektfunktionen zu erkennen, verwendet OpenTextTM Static Application Security Testing Regeln, die festlegen, wann in bestimmten Programmiersprachen und Frameworks eine Autorisierungsprüfung zu erwarten ist. Das Fehlen einer solchen Prüfung wird gemeldet.
API6:2023 – Uneingeschränkter Zugriff auf sensible Geschäftsabläufe
Was ist das?
Von Sneakerbots bis hin zu Ticketbots: Angriffe auf das Inventar von Online-Händlern über deren APIs sind zu einem erheblichen Problem für E-Commerce-Websites geworden. Durch das Verständnis des Geschäftsmodells und der Anwendungslogik kann ein Angreifer eine Reihe von API-Aufrufen erstellen, die automatisch reservieren oder kaufen können.
17 Beeferman, Jason. Persönliche Daten von 1.8 Millionen Texanern mit Versicherungsansprüchen waren jahrelang offengelegt, so eine Untersuchung. The Texas Tribune. 17. Mai 2022.
18 Taylor, Josh. Optus-Datenleck: Alles, was wir bisher über den Vorfall wissen. The Guardian. 28. September 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
14/23
Bei der Verhinderung des uneingeschränkten Zugriffs auf vertrauliche Geschäftsabläufe geht es weniger um die Suche nach einer bestimmten Technologie, sondern vielmehr um einen ganzheitlichen Ansatz für die Anwendungssicherheit.
Inventar und verhindert so, dass andere, legitime Verbraucher Zugriff auf die Produkte oder Dienstleistungen des Unternehmens erhalten. Jede API, die Zugriff auf einen Geschäftsprozess ermöglicht, kann von einem Angreifer genutzt werden, um das Unternehmen zu beeinflussen und fällt unter die Definition des uneingeschränkten Zugriffs auf vertrauliche Geschäftsabläufe.
Was macht eine Anwendung anfällig?
Anwendungssteuerung und Logikflüsse bilden das Herzstück jedes Online-Unternehmens. Da Unternehmen immer mehr ihrer Geschäftstätigkeit in die Cloud verlagern, können diese Abläufe offengelegt und ausgenutzt werden. Dieser übermäßige Zugriff kann dem Unternehmen schaden, wenn Angreifer den Kauf von Produkten automatisieren, Bots zum Hinterlassen von Kommentaren erstellen undviews oder die Reservierung von Waren oder Dienstleistungen automatisieren.
Bietet eine Anwendung einen Endpunkt, der Zugriff auf den Geschäftsablauf des Unternehmens bietet, ohne den Zugriff auf die dahinter liegenden Geschäftsvorgänge einzuschränken, ist die Anwendung anfällig. Schutzmaßnahmen umfassen die Begrenzung der Anzahl der Zugriffsversuche von einem einzelnen Gerät durch Fingerprinting, die Erkennung, ob die Aktivität von einem menschlichen Akteur ausgeht, und die Erkennung, ob Automatisierung im Spiel ist.
Angriff examples
Als Taylor Swift-Tickets im November 2022 bei Ticketmaster in den Verkauf gingen, hatten sich 1.5 Millionen Kunden vorregistriert, aber mehr als 14 Millionen Anfragen – darunter dreimal so viel Bot-Verkehr – wurden gesendet.amped the purchasing links and APIs as soon as ticket sales opened. The site crashed, preventing many customers from purchasing tickets.19
Der Ansturm der Reseller-Bots ähnelte jenem, der den Start der PlayStation 5 im November 2020 ruinierte. Lieferkettenprobleme hatten das Angebot bereits vor dem Start der neuesten Sony-Spielkonsole eingeschränkt, doch die automatisierten Bots erschwerten die Suche nach verfügbaren Einheiten zusätzlich und führten zu astronomischen Wiederverkaufspreisen. Im Fall einer E-Commerce-Site stieg die Anzahl der „In den Warenkorb“-Transaktionen von durchschnittlich 15,000 Anfragen pro Stunde auf über 27 Millionen, da die API des Shops genutzt wurde, um Produkte direkt nach Artikelnummer anzufordern.
Wie kann man dies als Entwickler verhindern?
Entwickler sollten sowohl mit den operativen als auch den technischen Teams zusammenarbeiten, um potenzielle böswillige Zugriffe auf Geschäftsabläufe zu verhindern. Die Fachteams können ermitteln, welche Abläufe über APIs offengelegt werden, und Bedrohungsanalysen durchführen, um zu ermitteln, wie Angreifer diese Endpunkte missbrauchen könnten. Gleichzeitig sollten Entwickler als Teil eines DevOps-Teams mit den technischen Teams zusammenarbeiten, um zusätzliche technische Abwehrmaßnahmen zu etablieren, beispielsweise durch Geräte-Fingerprinting, um eine Überlastung durch automatisierte Browser-Instanzen zu verhindern, und durch die Identifizierung von Verhaltensmustern, die zwischen menschlichen und maschinellen Akteuren unterscheiden.
19 Steele, Billy. Ticketmaster weiß, dass es ein Bot-Problem hat, will aber, dass der Kongress es behebt. Engadget. Nachrichtenartikel. 24. Januar 2023.
20 Muwandi, Tafara und Warburton, David. Wie Bots den Start der PlayStation 5 für Millionen von Spielern ruinierten. F5 Labs Blog. F5. Web Seite. 18. März 2023.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
15/23
Der bekannteste ExampAn einem SSRF-Angriff war ein ehemaliger Amazon- Web Services (AWS)-Ingenieur, der eine falsch konfigurierte web Application Firewall (WAF), um dann einen SSRF-Fehler auszunutzen und Daten von einer Serverinstanz des Finanzgiganten Capital One zu sammeln.
Betriebsteams sollten auchview alle APIs, die für die Verwendung durch andere Maschinen konzipiert sind, beispielsweise für B2B-Anwendungsfälle, und stellen Sie sicher, dass einige Abwehrmaßnahmen vorhanden sind, um zu verhindern, dass Angreifer Interaktionen zwischen Maschinen ausnutzen.
Wie kann OpenText helfen?
Das Aufspüren anfälliger und sensibler Geschäftsabläufe erfordert oft grundlegende Kenntnisse. Unternehmen müssen alle funktionierenden APIs dokumentieren und verfolgen und feststellen, welche sensible Prozesse und Daten potenziellen Angreifern aussetzen. Die Anwendungslogik muss außerdem auf Logikfehler analysiert werden, die von Angreifern ausgenutzt werden könnten.
Insgesamt geht es bei der Verhinderung des uneingeschränkten Zugriffs auf vertrauliche Geschäftsabläufe eher um einen ganzheitlichen Ansatz zur Anwendungssicherheit und weniger darum, eine bestimmte Technologie zu finden.
API7:2023 – Serverseitige Anforderungsfälschung
Was ist das?
Backend-Server verarbeiten Anfragen über API-Endpunkte. Server-Side Request Forgery (SSRF) ist eine Schwachstelle, die es Angreifern ermöglicht, einen Server dazu zu bringen, Anfragen in ihrem Namen und mit den gleichen Berechtigungen zu senden. Oftmals nutzt der Angriff den Server, um die Lücke zwischen dem externen Angreifer und dem internen Netzwerk zu schließen. Einfache SSRF-Angriffe führen zu einer Antwort an den Angreifer – ein deutlich einfacheres Szenario als Blind-SSRF-Angriffe, bei denen keine Antwort zurückgegeben wird und der Angreifer keine Bestätigung erhält, ob der Angriff erfolgreich war.
Was macht eine Anwendung anfällig?
Server-Side Request Forgery (SSRF)-Schwachstellen sind im Wesentlichen auf eine mangelnde Validierung der Benutzereingaben zurückzuführen. Angreifer können Anfragen erstellen und eine URI einfügen, die Zugriff auf die Zielanwendung gewährt.
Moderne Konzepte in der Anwendungsentwicklung, wie beispielsweise webHooks und standardisierte Anwendungsframeworks machen SSRF laut OWASP häufiger und gefährlicher.
In einer Example zitiert von OWASP, einem sozialen Netzwerk, das Benutzern das Hochladen von Pro ermöglichtfile Bilder könnten anfällig für SSRF sein, wenn der Server die an die Anwendung gesendeten Argumente nicht validiert. Anstatt eines URL auf ein Bild zeigen, wie etwa:
POST /api/profile/Bild hochladen
{
"Bild _ url”: “http://example.com/profile _ pic.jpg”
}
Ein Angreifer könnte mithilfe des folgenden API-Aufrufs eine URI senden, mit der ermittelt werden könnte, ob ein bestimmter Port geöffnet ist:
{ "Bild _ url”: „localhost:8080“
}
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
16/23
Zu den Sicherheitsfehlkonfigurationen zählen das Einrichten von Anwendungen mit anfälligen Standardkonfigurationen, das Erlauben eines übermäßig freizügigen Zugriffs auf vertrauliche Funktionen und Daten und die öffentliche Offenlegung von Anwendungsinformationen durch detaillierte Fehlermeldungen.
Selbst im Fall von Blind-SSRF könnte ein Angreifer herausfinden, ob der Port geöffnet ist, indem er die Zeit misst, die benötigt wird, um eine Antwort zu erhalten.
Angriff examples
Der bekannteste ExampAn einem SSRF-Angriff war ein ehemaliger Amazon- Web Services (AWS)-Ingenieur, der eine falsch konfigurierte web Amazon nutzte eine Sicherheitslücke in der Application Firewall (WAF), um Daten von einer Serverinstanz des Finanzriesen Capital One zu sammeln. Der Vorfall ereignete sich im Juli 2019 und führte zum Diebstahl von Daten von rund 100 Millionen US-Bürgern und sechs Millionen kanadischen Bürgern.21 Amazon sieht die Ursache für den Angriff in der Fehlkonfiguration und nicht in der SSRF-Schwachstelle.22
Im Oktober 2022 informierte ein Cloud-Sicherheitsunternehmen Microsoft über vier SSRF-Schwachstellen in der Azure-Cloud-Plattform des Unternehmens. Jede Schwachstelle betraf einen anderen Azure-Dienst, darunter den Azure Machine Learning-Dienst und den Azure API Management-Dienst.
Wie kann man dies als Entwickler verhindern?
Entwickler sollten die Mechanismen zum Ressourcenabruf in ihrem Code kapseln, die Funktion isolieren und zusätzliche Schutzmechanismen implementieren, um alle Anfragen zu überprüfen. Da solche Funktionen typischerweise zum Abrufen von Remoteressourcen und nicht von internen Ressourcen verwendet werden, sollten Entwickler die gekapselten Funktionen so konfigurieren, dass sie eine Liste zulässiger Remoteressourcen verwenden und Zugriffsversuche auf interne Ressourcen blockieren. Die HTTP-Umleitung sollte für die Funktionen zum Ressourcenabruf deaktiviert und alle Anfragen auf Schadcode analysiert werden.
Das Risiko von SSRF-Schwachstellen lässt sich nicht immer vollständig ausschließen. Unternehmen sollten daher das Risiko von Anrufen an externe Ressourcen genau abwägen.
Wie kann OpenText helfen?
OpenText Dynamic Application Security Testing ermöglicht DevSecOps-Teams regelmäßige Tests auf Server-Side Request Forgery. OpenTextTM Dynamic Application Security Testing scannt einen Anwendungsserver in einer konfigurierten Umgebung, sodass alle Komponenten – Anwendung, Server und Netzwerk – getestet werden können. Dies bietet der dynamischen Analyseplattform eine umfassende view der Auswirkungen von Serveranforderungen.
OpenText SAST kann viele Fälle von SSRF durch Taint-Analyse erkennen – zum BeispielampWenn die Anwendung nicht validierte Benutzereingaben verwendet, um eine URL Diese werden dann abgerufen. Das Tool kennzeichnet die Verwendung uneingeschränkter Benutzereingaben.
21 Informationen zum Cyber-Vorfall bei Capital One. Capitol One Advisory. Web Seite. Aktualisiert am 22. April 2022.
22 Ng, Alfred. Amazon erklärt Senatoren, es sei nicht für den Datendiebstahl bei Capital One verantwortlich. CNET News.com. Nachrichtenartikel. 21. November 2019.
23 Shitrit, Lidor Ben. Wie Orca Server-Side Request Forgery (SSRF)-Schwachstellen in vier verschiedenen Azure-Diensten fand. Orca Security Blog. Web Seite. 17. Januar 2023.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
17/23
Security-as-Code kann dabei helfen, indem es Konfigurationen wiederholbar macht und Anwendungssicherheitsteams die Möglichkeit gibt, Standardkonfigurationssätze für bestimmte Anwendungskomponenten festzulegen.
API8:2023–Sicherheitsfehlkonfiguration
Was ist das?
Entwickler konfigurieren ihre Anwendungen oft falsch, trennen Entwicklungsressourcen nicht von Produktionsressourcen und exportieren sensible files–such-Konfiguration files– in ihre öffentlichen Repositorien und das Versäumnis, Standardkonfigurationen zu ändern. Zu den Sicherheitsfehlkonfigurationen gehören das Einrichten von Anwendungen mit anfälligen Standardkonfigurationen, das Erlauben eines übermäßig freizügigen Zugriffs auf sensible Funktionen und Daten und die öffentliche Offenlegung von Anwendungsinformationen durch detaillierte Fehlermeldungen.
Was macht eine Anwendung anfällig?
Standardmäßige Anwendungskonfigurationen sind oft zu freizügig, bieten keine Sicherheitsvorkehrungen und lassen Cloud-Speicherinstanzen für die Öffentlichkeit zugänglich. Oftmals web Frameworks, auf denen Anwendungen basieren, enthalten eine Vielzahl von Anwendungsfunktionen, die nicht benötigt werden und deren Einbeziehung die Sicherheit verringert.
In einer ExampWie von OWASP detailliert beschrieben, sollte ein soziales Netzwerk, das eine Direktnachrichtenfunktion bietet, die Privatsphäre der Benutzer schützen, bietet aber eine API-Anfrage zum Abrufen einer bestimmten Konversation mithilfe des folgenden Beispielsample API-Anfrage:
GET /dm/user _ updates.json?conversation _ id=1234567&cursor=GRlFp7LCUAAAA
Der API-Endpunkt schränkt die im Cache gespeicherten Daten nicht ein, was dazu führt, dass private Konversationen von der web Browser. Angreifer könnten die Informationen aus dem Browser abrufen und so die privaten Nachrichten des Opfers offenlegen.
Angriff examples
Im Mai 2021 informierte ein Cloud-Sicherheitsunternehmen Microsoft darüber, dass mindestens 47 verschiedene Kunden die Standardkonfiguration ihrer Microsoft Power Apps-Instanzen nicht geändert hatten. Zu den betroffenen Organisationen gehörten Unternehmen wie American Airlines und Microsoft sowie Landesregierungen wie die von Indiana und Maryland. 38 Millionen Datensätze waren über die Power Apps-Portale potenziell gefährdet.
Im Jahr 2022 entdeckte ein Unternehmen für Schwachstellenmanagement, dass 12,000 Cloud-Instanzen auf Amazon gehostet wurden Web Dienste und 10,500 auf Azure gehostete Dienste setzten weiterhin Telnet aus, ein Fernzugriffsprotokoll, das laut einem Bericht aus dem Jahr 2022 „für jede internetbasierte Nutzung heute ungeeignet“ ist.25 Die Einbeziehung unnötiger und unsicherer Funktionen untergräbt die Sicherheit der APIs und Anwendungen.
24 Upguard Research. By Design: Wie Standardberechtigungen in Microsoft Power Apps Millionen von Menschen gefährdeten. Upgard Research Blog. Web Seite. 23. August 2021.
25 Beardsley, Todd. Bericht zu Cloud-Fehlkonfigurationen 2022. Rapid7. PDF-Bericht. S. 12. 20. April 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
18/23
Ein blinder Fleck in der Dokumentation liegt vor, wenn die Einzelheiten zu Zweck, Funktionsweise und Versionierung der API unklar sind, weil es keine Dokumentation zu diesen wichtigen Attributen gibt.
Wie kann man das als Entwickler verhindern?
DevSecOps-Teams müssen die notwendigen Schritte verstehen, um sichere Konfigurationen für ihre Anwendungen zu erstellen und eine automatisierte Entwicklungspipeline zur Überprüfung der Konfiguration zu verwenden. files vor der Bereitstellung, einschließlich regelmäßiger Unit-Tests und Laufzeitprüfungen, um die Software kontinuierlich auf Konfigurationsfehler oder Sicherheitsprobleme zu prüfen. Security-as-Code kann helfen, indem es Konfigurationen wiederholbar macht und Anwendungssicherheitsteams die Möglichkeit gibt, Standardkonfigurationssätze für bestimmte Anwendungskomponenten festzulegen.
Im Rahmen ihres sicheren Entwicklungslebenszyklus sollten Entwickler und Betriebsteams:
· Etablierung eines Härtungsprozesses, der die wiederholbare Erstellung und Aufrechterhaltung einer sicheren Anwendungsumgebung vereinfacht,
· Betreffview und aktualisieren Sie alle Konfigurationen im gesamten API-Stack, um den neuen Standard konsistent zu integrieren, und
· Automatisieren Sie die Bewertung der Wirksamkeit der Konfigurationseinstellungen in allen Umgebungen.
Wie kann OpenText helfen?
OpenText Static Application Security Testing kann Konfigurationen während des Entwicklungsprozesses überprüfen und zahlreiche Schwachstellen aufdecken. Da Sicherheitsfehlkonfigurationen sowohl auf Anwendungscode- als auch auf Infrastrukturebene auftreten, können verschiedene OpenText-Produkte zum Aufspüren von Fehlkonfigurationen eingesetzt werden.
OpenText Static Application Security Testing-Scans können den Anwendungscode auf Fehlkonfigurationen prüfen. Während der statischen Analyse kann OpenText SAST die Konfiguration bewerten. files für Sicherheitsfehler, einschließlich derer für Docker, Kubernetes, Ansible, Amazon Web Services-, CloudFormation-, Terraform- und Azure Resource Manager-Vorlagen.
Konfigurationsfehler können auch während der Laufzeit erkannt werden. OpenText Dynamic Application Security Testing ermöglicht DevSecOps-Teams, regelmäßig auf häufige Sicherheitsfehlkonfigurationen zu testen. Eine der größten Stärken des DAST-Scannings besteht darin, dass es auf dem Anwendungsserver in einer konfigurierten Umgebung ausgeführt wird. Das bedeutet, dass die gesamte Umgebung – Anwendung, Server und Netzwerk – gleichzeitig getestet wird. Dies bietet der dynamischen Analyseplattform eine umfassende view der Produktionsumgebung konfiguriert ist.
API9:2023 – Unsachgemäße Bestandsverwaltung
Was ist das?
Like most software assets, APIs have a lifecycle, with older versions replaced by more secure and efficient APIs or, increasingly, using API connected to third-party services. DevSecOps teams who do not maintain their API versions and documentation can introduce vulnerabilities when older, flawed API versions continue to be used–a weakness known as Improper Inventory Management. Best practices for inventory management require the tracking of
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
19/23
API-Versionen, die regelmäßige Bewertung und Inventarisierung integrierter Dienste und die regelmäßige Abwertung älterer Versionen, um die Verbreitung von Sicherheitslücken zu verhindern.
Was macht eine Anwendung anfällig?
Softwarearchitekturen, die auf APIs basieren – insbesondere solche, die Microservice-Architekturen verwenden – neigen dazu, mehr Endpunkte offenzulegen als herkömmliche web Anwendungen. Die Vielzahl der API-Endpunkte und die Wahrscheinlichkeit, dass mehrere Versionen einer API gleichzeitig existieren, erfordern zusätzliche Verwaltungsressourcen des API-Anbieters, um eine wachsende Angriffsfläche zu verhindern. OWASP identifiziert zwei große Schwachstellen, die DevSecOps-Teams in Bezug auf ihre API-Infrastruktur haben können.
Erstens liegt ein blinder Fleck in der Dokumentation vor, wenn die Einzelheiten zu Zweck, Funktionsweise und Versionierung der API unklar sind, weil es keine Dokumentation zu diesen wichtigen Attributen gibt.
Zweitens entsteht ein Datenfluss-Blindspot, wenn APIs unübersichtlich eingesetzt werden. Dies führt zu Funktionen, die ohne eine überzeugende geschäftliche Begründung nicht unbedingt erlaubt sein sollten. Die Weitergabe sensibler Daten an Dritte ohne Sicherheitsgarantien, die fehlende Transparenz des Endergebnisses eines Datenflusses und die fehlende Abbildung aller Datenflüsse in verketteten APIs sind allesamt blinde Flecken.
Als ExampDer OWASP-Bericht zitiert ein fiktives soziales Netzwerk, das die Integration mit unabhängigen Anwendungen von Drittanbietern ermöglicht. Zwar ist die Zustimmung des Endnutzers erforderlich, doch das soziale Netzwerk bietet nicht genügend Einblick in den Datenfluss, um nachgelagerte Parteien am Zugriff auf die Daten zu hindern, beispielsweise durch die Überwachung der Aktivitäten nicht nur des Nutzers, sondern auch seiner Freunde.
Angriff examples
In den Jahren 2013 und 2014 nahmen bis zu 300,000 Menschen an einem psychologischen Online-Quiz auf der Facebook-Plattform teil. Das Unternehmen hinter dem Quiz, Cambridge Analytica, sammelte nicht nur Informationen über diese Nutzer, sondern auch über ihre verlinkten Freunde – insgesamt bis zu 87 Millionen Menschen, von denen die überwiegende Mehrheit keine Einwilligung zur Datenerfassung erteilte. Das Unternehmen nutzte die Informationen anschließend, um im Auftrag seiner Kunden Werbung und Nachrichten an diese Personen anzupassen, darunter auch politische Anzeigen zur Unterstützung der Trump-Bewegung.ampaign bei der Wahl 2016 Facebooks mangelnde Transparenz darüber, wie Dritte die von seiner Plattform gesammelten Informationen nutzten, ist ein Example von unsachgemäßer Bestandsverwaltung.
Wie kann man dies als Entwickler verhindern?
DevSecOps-Teams sollten alle API-Hosts dokumentieren und sich darauf konzentrieren, die Datenflüsse zwischen APIs und Drittanbieterdiensten transparent zu halten. Der wichtigste Weg, unsachgemäßes Bestandsmanagement zu verhindern, ist die detaillierte Dokumentation der kritischen Aspekte aller API-Dienste und -Hosts, einschließlich Informationen darüber, welche Daten sie verarbeiten und wer Zugriff auf die Hosts und Daten hat.
26 Rosenberg, Matthew und Dance, Gabriel. „Du bist das Produkt“: Im Visier von Cambridge Analytica auf Facebook. The New York Times. Nachrichtenartikel. 8. April 2018.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
20/23
Organisationen können ihre API-Nutzung mit dem OpenText Secure API Manager von OpenText verwalten, überwachen, sichern und dokumentieren. Dadurch können Anwendungssicherheitsteams ein aktuelles Inventar der API-Assets pflegen.
und die spezifischen API-Versionen jedes Hosts. Zu den technischen Details, die dokumentiert werden sollten, gehören die Authentifizierungsimplementierung, die Fehlerbehandlung, die Ratenbegrenzungsmaßnahmen, die CORS-Richtlinie (Cross-Origin Resource Sharing) und Details zu jedem Endpunkt.
Der umfangreiche Dokumentationsumfang lässt sich manuell nur schwer verwalten. Daher empfiehlt es sich, die Dokumentation mithilfe des Continuous-Integration-Prozesses und unter Verwendung offener Standards zu erstellen. Der Zugriff auf die API-Dokumentation sollte außerdem auf Entwickler beschränkt sein, die zur Nutzung der API berechtigt sind.
Während der Anwendungserstellungs- und Testphasen sollten Entwickler die Verwendung von Produktionsdaten auf Entwicklungs- oder s vermeidentagaktualisierte Versionen der Anwendung, um Datenlecks zu verhindern. Wenn neue Versionen von APIs veröffentlicht werden, sollte das DevSecOps-Team eine Risikoanalyse durchführen, um den besten Ansatz für die Aktualisierung von Anwendungen zu ermitteln, um die Vorteile zu nutzen.tage der erhöhten Sicherheit.
Wie kann OpenText helfen?
Unternehmen können ihre API-Nutzung mit dem OpenText Secure API Manager verwalten, überwachen, sichern und dokumentieren. Anwendungssicherheitsteams können so ein aktuelles Inventar ihrer API-Ressourcen pflegen. OpenText Secure API Manager bietet ein zuverlässiges Repository, in dem Ihr DevSecOps-Team alle im Unternehmen verwendeten APIs speichern und verwalten kann. Dies ermöglicht einen einfach zu verwaltenden Lebenszyklus von der API-Entwicklung bis zur Außerbetriebnahme. Die Software trägt durch detaillierte Analysen zur verbesserten Einhaltung von Vorschriften und Lizenzen bei.
API10:2023 – Unsichere Nutzung von APIs
Was ist das?
Mit dem Anstiegasing use of native cloud infrastructure to create applications, APIs have become the point of integration between application components. However, the security posture of third-party services accessed through APIs is rarely clear, allowing attackers to determine on which services an application relies and whether any of those services have security weaknesses. Developers tend to trust the endpoints that their application interacts without verifying the external or third-party APIs. This Unsafe Consumption of APIs often leads to the application’s reliance on services that have weaker security requirements or lack fundamental security hardening, such as input validation.
Was macht eine Anwendung anfällig?
Entwickler vertrauen Daten von Drittanbieter-APIs tendenziell mehr als Benutzereingaben, obwohl beide Quellen für einen motivierten Angreifer im Wesentlichen gleichwertig sind. Aufgrund dieses fehlgeleiteten Vertrauens verlassen sich Entwickler aufgrund fehlender Eingabevalidierung und -bereinigung letztlich auf schwächere Sicherheitsstandards.
Eine unsichere Verwendung von APIs kann auftreten, wenn die Anwendung:
· Verwendet oder nutzt andere APIs mithilfe unverschlüsselter Kommunikation,
· Die Validierung und Bereinigung von Daten aus anderen APIs oder Diensten schlägt fehl.
· Ermöglicht die Umleitung ohne Sicherheitsüberprüfungen oder
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
21/23
Wenn der Entwickler in seine Anwendung keine Sicherheitsüberprüfungen einprogrammiert, um die vom API-Endpunkt zurückgegebenen Daten zu überprüfen, folgt seine Anwendung der Umleitung und sendet vertrauliche medizinische Informationen an den Angreifer.
Die OWASP API Security Top-10 ist für Cloud-native-Entwickler, die APIs erstellen, von entscheidender Bedeutung. Die Behebung gängiger Anwendungsschwachstellen wie SQL-Injection, Datenverlust und Sicherheitsfehlkonfigurationen sollte jedoch Priorität haben, da diese häufig von Cyberbedrohungen ausgenutzt werden. Die API Security Top-10 ist ein wesentlicher Bestandteil sicherer Softwareentwicklung, sollte aber gegenüber der Behebung allgemeiner Anwendungsschwachstellen zweitrangig sein.
· Der Ressourcenverbrauch kann nicht durch Schwellenwerte und Zeitüberschreitungen begrenzt werden.
In einer ExampLaut dem OWASP-Bericht könnte eine API, die mit einem Drittanbieter-Dienstanbieter integriert ist, um sensible medizinische Benutzerinformationen zu speichern, private Daten über einen API-Endpunkt senden. Angreifer könnten den Drittanbieter-API-Host so manipulieren, dass er auf zukünftige Anfragen mit einer 308-Permanent-Umleitung antwortet: HTTP/1.1 308-Permanent-Umleitung
Standort: https://attacker.com/
Wenn der Entwickler in seine Anwendung keine Sicherheitsüberprüfungen einprogrammiert, um die vom API-Endpunkt zurückgegebenen Daten zu überprüfen, folgt seine Anwendung der Umleitung und sendet vertrauliche medizinische Informationen an den Angreifer.
Angriff examples
Im Dezember 2021 ermöglichten Schwachstellen in der häufig verwendeten Open-Source-Softwarekomponente Log4J einem Angreifer, unsaubere Eingaben, beispielsweise ein verschlüsseltes Skript, bereitzustellen und anfällige Versionen von Log4J zu verwenden, um das Skript auf dem Server auszuführen. Das Problem der Log4J-Schwachstelle lag in einer fehlenden Eingabevalidierung, insbesondere in der fehlenden Durchführung von Sicherheitsüberprüfungen der deserialisierten, vom Benutzer bereitgestellten Daten. Durch das Senden serialisierten Schadcodes konnten Angreifer die Schwachstelle ausnutzen und einen Angriff auf einen betroffenen Server ausführen. Entwickler sollten alle Eingaben von Drittanbieter-APIs und anderen externen Quellen überprüfen.
Wie kann man das als Entwickler verhindern?
Entwickler sollten bei der Bewertung von Dienstanbietern sorgfältig vorgehen, deren API-Sicherheitslage bewerten und strenge Sicherheitskontrollen implementieren. Darüber hinaus sollten Entwickler sicherstellen, dass die gesamte Kommunikation mit APIs von Drittanbietern und von Drittanbietern mit den APIs des Unternehmens über einen sicheren Kommunikationskanal erfolgt, um Schnüffel- und Replay-Angriffe zu verhindern.
Beim Empfang von Daten von externen Nutzern und Rechnern sollten die Eingaben stets bereinigt werden, um die unbeabsichtigte Ausführung von Code zu verhindern. Bei über APIs integrierten Cloud-Diensten sollten außerdem Zulassungslisten verwendet werden, um die Adresse der integrierten Lösung zu sperren, anstatt blind jeder IP-Adresse den Aufruf der Anwendungs-API zu erlauben.
Wie kann OpenText helfen?
Durch die Kombination der statischen Code- und API-Analysefunktionen von OpenText Static Application Security Testing mit den Laufzeitprüfungen der OpenText Dynamic Application Security Testing (DAST) Suite können DevSecOps-Teams die Nutzung von Drittanbieter-APIs in ihrer Anwendung überprüfen und gängige Angriffsarten testen. Um unsichere APIs zu identifizieren, erstellt OpenText Secure API Manager ein Repository aller vom System aufgerufenen APIs sowie der externen Anwendungen, die die APIs Ihrer Anwendung nutzen können.
27 Microsoft Threat Intelligence. Anleitung zur Verhinderung, Erkennung und Suche nach Ausnutzung der Log4j 2-Sicherheitslücke. Microsoft. Web Seite. Aktualisiert: 10. Januar 2022.
Entwicklerhandbuch zu den OWASP Top 2023 für API-Sicherheit 10
22/23
Wohin als nächstes?
Hier sind die in diesem Dokument erwähnten Produkte: OpenText Application Security >
Statische Anwendungssicherheitstests von OpenText >
OpenText Dynamisches Testen der Anwendungssicherheit >
OpenText Secure API Manager >
Zusätzliche Ressourcen OWASP Top 10 API-Sicherheitsrisiken–2023 >
Gartner Magic Quadrant für Anwendungssicherheitstests >
OpenText Anwendungssicherheit Webinar-Serie >
Die API Security Top-10 reichen nicht aus!
Für Cloud-native-Entwickler, die sich speziell auf die Erstellung von APIs konzentrieren, um Dienste für andere Teile einer Anwendung, interne Benutzer oder für die globale Nutzung anzubieten, ist die OWASP API Security Top 10-Liste ein wichtiges Dokument zum Lesen und Verstehen.
Die OWASP API Security Top 10 sind jedoch kein eigenständiges Dokument. Entwickler müssen auch sicherstellen, dass sie andere Best Practices-Quellen wie die OWASP Top 10 nutzen, die für ihre aktuelle Anwendung und Architektur relevant sind. Gängige Anwendungsschwachstellen – SQL-Injection, Datenfreigabe und Sicherheitsfehlkonfigurationen – sind nach wie vor häufige Wege, wie Cyberkriminelle Unternehmensinfrastrukturen kompromittieren können und sollten schnell behoben werden. Darüber hinaus erfordern einige API-basierte Anwendungen, wie z. B. mobile Apps, andere Schritte zur Appsec-Härtung als ein eigenständiges Dokument. web-App und unterscheiden sich möglicherweise von den Anforderungen für Connect- und IoT-Geräte. Insgesamt ist die API Security Top 10-Liste zwar wichtig, stellt aber nur einen Aspekt des gesamten sicheren Softwareentwicklungszyklus dar. Die Liste und die OWASP Top 10-Liste sollten in Verbindung mit allen anderen relevanten Standards und Best Practices verwendet werden, die für die zu analysierende Lösung erforderlich sind.
Abschluss
As applications increasingly rely on cloud infrastructure, web application programming interfaces (APIs) have become the foundation of the Internet. Companies typically have hundreds, if not thousands, of API endpoints in their environment, dramatically increasing their attack surface and exposing applications to a variety of weaknesses.
Die Veröffentlichung der OWASP API Security Top 2023-Liste 10 ist ein guter Ausgangspunkt für Unternehmen und Entwickler, um sich über die Risiken API-basierter Infrastrukturen zu informieren und ihre eigenen Anwendungen zu bewerten. Zusammen mit der bekannteren Application Security Top 10-Liste können die beiden Rankings DevSecOps-Teams dabei unterstützen, einen ganzheitlichen Ansatz für die Gesamtsicherheit ihrer Anwendungen zu entwickeln.
DevSecOps-Teams müssen sich der Sicherheitsauswirkungen von APIs bewusst sein, wissen, wie sie die Schwachstellen und Sicherheitsmängel einer Implementierung reduzieren und wie sie ihre Entwicklungspipeline und den daraus resultierenden API-Server härten können, um es Angreifern zu erschweren, eine Anwendung über ihre APIs zu kompromittieren.
Copyright © 2025 Offener Text · 04.25 | 262-000177-001
Dokumente / Ressourcen
 |
OpenText 262-000177-001 OWASP Top 10 für API-Sicherheit [pdf] Benutzerhandbuch 262-000177-001, 262-000177-001 OWASP Top 10 für API-Sicherheit, 262-000177-001, OWASP Top 10 für API-Sicherheit, für API-Sicherheit, API-Sicherheit, Sicherheit |