Die Verlagerung von HTML-basierenden Webseiten hin zu REST basierenden Programmierschnittstellen schreitet rasch voran. OWASP publiziert darum eine neue und spezialisierte Top 10 Liste für API Security. Dedizierte Sicherheitsprodukte, wie Web Application Firewalls, API Gateways mit entsprechenden Erweiterungen und Identity und Access Management Systeme, wie von Airlock, können einen wesentlichen Beitrag zur Sicherung von APIs beitragen, aber auch Entwickler müssen in die Pflicht genommen werden und ihren Teil leisten, um einen optimalen Schutz der Ressourcen des Unternehmens zu gewährleisten.
Die Bedeutung von HTML basierenden Webseiten und Portalen nimmt seit einigen Jahren ab. Die Gründe dafür sind vielfältig. Einen wichtigen Teil trägt die zunehmende Verwendung von Smartphones und Tablets dazu bei, weil es effizienter und kostengünstiger ist, wenn Applikationen bereits im Gerät installiert sind und nur noch die Daten über das Internet geladen werden müssen. IoT Geräte und Wearables sind meist zu klein um Webseiten darstellen und bedienen zu können aber der Datenaustausch über das Internet ist ein Schlüsselelement für deren Einsatz. Die kontinuierliche Weiterentwicklung von Web Browsern erlaubt es den Entwicklern heute eine optimale User Experience umzusetzen, die sich automatisch den Rahmenbedingungen des verwendeten Devices anpassen kann. Diesen Entwicklungen gemeinsam ist die Tatsache, dass die Daten aus dem Internet bezogen werden und für die dafür nötigen REST Schnittstellen sich deshalb immer mehr zu einem der wichtigsten Bausteine der Internet Architektur entwickeln.
APIs im Dienste der User Experience
Die zunehmende Bedeutung von REST Schnittstellen ist dem Umstand geschuldet, dass sich die Architekturparadigmen der Applikationsentwicklung an die Anforderungen der User anpassen mussten. Mobile First führt dazu, dass moderne Applikationen entweder direkt als native mobile Applikationen entwickelt oder als Single Page Applications (SPA) direkt im Browser ausgeführt werden. Dabei können diese Applikationen ein Vielzahl von APIs von ganz unterschiedlichen Quellen nutzen und erst im Client zusammenfügen. Unterstützt werden die Software Entwickler durch grosse und funktional sehr umfangreiche Ökosysteme: Android Studio, Xcode, React oder Angular um nur ein paar zu nennen. Als Resultat entstehen so Applikationen, die eine User Experience ermöglichen, die sehr nahe an derjenigen von Rich Clients ist ohne aber deren Nachteile akzeptieren zu müssen.
Aus Sicht der API Anbieter geht es darum eine Kombination von Business Logik und Daten so zu exponieren, dass die Applikationen diese effizient und gefahrlos nutzen können. Dies bedeutet, dass jeder API Anbieter selbst die Sicherheit der angebotenen API sicher stellen muss. Ein delegieren dieser Verantwortung an vorgelagerte Applikationen oder Portale ist nicht möglich, denn APIs müssen direkt im Internet exponiert werden.
Die Evolution der REST Schnittstellen basiert auf dem gleichen HTTP Protokoll welches bereits für HTML basierende Webseiten so erfolgreich war. Darum ist es nicht erstaunlich, dass viele potentielle Angriffe sehr viel Ähnlichkeiten zu den Angriffen auf traditionelle Webseiten oder Portale aufweisen. Gemäss einer Studie von Gartner zur API Security [1] ensteht bis 2021 die grösste Angriffsfläche bei 90% der Web-Applikationen durch exponierte APIs. Bis 2022 wird der API Missbrauch zum wichtigsten Angriffsvektor und global zu Data Breaches führen. Aber bereits heute gibt es genügend Berichte von Zwischenfällen die auf schlecht gesicherte APIs zurück zu führen sind.
System Owner | Date | Effect of Data Leaks | Citation |
US Postal Services Hack | 21.11.2018 | Alle Benutzerkonten, inckl. Adresse, Telefonnummer und E-Mail | https://krebsonsecurity.com/2018/11/usps-site-exposed-data-on-60-million-users/ |
Brazil Fed of Indus - ElasticSearch API exposed | 23.11.2018 | 34.8 Mio. Benutzerkonten | https://www.zdnet.com/article/brazils-largest-professional-association-suffers-massive-data-leak/ |
Urban Massage - ElasticSearch API exposed | 27.11.2018 | 309'000 Benutzerkonten, inkl. Transaktionsdaten | https://techcrunch.com/2018/11/27/urban-massage-data-exposed-customers-creepy-clients/ |
SKY Brasil - ElasticSearch API exposed | 29.11.2018 | 32 Mio. Benutzerkonten, 492 GB API Daten | https://www.zdnet.com/article/sky-brasil-exposes-data-of-32-million-subscribers/ |
Atrium Health - ElasticSearch API exposed | 29.11.2018 | 2 Mio Patienten, inkl. Sozialversicherungsnummer, Geburtsdatum. Keine medizinischen Daten | |
Data&Leads | 29.11.2018 | 44.3 Mio. Benutzerkonten | https://www.bankinfosecurity.com/blogs/data-leads-site-disappears-after-data-exposure-alert-p-2687 |
Smart Watches PWNED | 2.4.2019 | Kontrolle über hunderte von Smart Watches | |
JustDial Leak | 17.4.2019 | 100 Mio Benutzerkonten inkl. Mobiltelefonnummern | https://thehackernews.com/2019/04/justdial-hacked-data-breach.html |
GateHub Cryptocurrency Wallet Hack | 6.6.2019 | Cryptogeld aus XRP Ledger Wallets gestoheln | |
Venmo transactions Leaked | 16.6.2019 | 7 Mio. Transaktionen | https://techcrunch.com/2019/06/16/millions-venmo-transactions-scraped/ |
Suprema: "Biostar 2" (Biometrie DB) |
| 27.8 Mio Benutzerprofile Profildaten, Usernamen, Passwörter, Gesichtsbilder, Fingerabdrücke, | |
Adobe Creative Cloud - ElasticSearch API exposed | 26.10.2019 | 7.5 Mio Benutzerkonten | |
OnePlus räumt Datenleck ein | 23.11.2019 | Benutzerkonten mit Adresse, Telefonnummern und E-Mail. |
[1] “API Security: What You Need to Do to Protect Your APIs”, Mark O'Neill, Dionisio Zumerle, Jeremy D'Hoinne, Gartner, 28.8.2019
Datensicherheit und Datenschutz
Im Gesundheitswesen ist der rasche und zuverlässige Austausch von strukturierten medizinischen Daten eine Anforderung die Ärzte und vermehrt auch Patienten immer lauter stellen. Die Realität zeigt aber, dass der Austausch häufig noch darin besteht, dass eingescannte Dokumente oder PDF über Fax und E-Mail übermittelt werden. In den letzten zwei Jahren kommt aber Bewegung ins Gesundheitswesen, weil die grossen IT Anbieter: Apple, Google, Microsoft und Amazon aktiv ins Thema "Personal Health Record" investieren und alle auf den gleichen Standard setzen: FHIR. FHIR beschreibt eine REST Schnittstelle mit Funktionen und Daten und ermöglicht so den Datenaustausch von strukturierten, medizinischen Daten. FHIR wird von den grossen Anbietern als Schlüsseltechnologie positioniert um den Datenaustausch zwischen Behandelnden und Patienten zu realisieren. Damit erfüllt FHIR aber auch alle Voraussetzungen um im gesamten Gesundheitswesen zum Austauschstandard zu werden.
Einen Schritt weiter ist der Bereich der Finanzdienstleister. In der EU wurde mit PSD2 ein Gesetz erlassen, dass alle Banken zwingt im Internet REST Schnittstellen anzubieten, welche für die Abfrage von Kontoinformationen und die Erfassung von Zahlungsaufträgen genutzt werden können. Dies hat dazu geführt, dass auf der Basis der gesetzlichen Vorlage bereits mehrere Standards entstanden sind, welche die für die Umsetzung nötigen REST Schnittstellen im Detail spezifizieren. Die Ausstrahlung der Europäischen Gesetzgebung ist aber enorm. Im Dokument von PwC kann man nachlesen, dass diese Entwicklung global Schule macht und auch in den USA und in Asien Empfehlungen oder Gesetze in Vorbereitung sind.
Damit setzen sich REST Schnittstellen in zwei Bereichen durch, die ein erhöhtes Maß an IT-Security aufweisen. Bei FHIR geht es um Gesundheitsdaten, für die die GDPR ganz unmissverständliche festlegt, dass es sich hier um besonders schützenswerte, sensible Daten handelt und andererseits geht es bei PSD2 um Anwendungen der Finanzbranche wo die Kunden klare Erwartungen bezüglich der Sicherheit ihres Vermögens haben und wo jedes mögliche Reputationsrisiko sehr ernst genommen wird.
OWASP Top Ten und OWASP API Security
Wenn es darum geht über die Risiken und Bedrohungen von Applikationen im Internet zu diskutieren, dann führt kein Weg an den OWASP Top 10 vorbei. Die OWASP ist eine non-Profit Organisation und die Top 10 sind das vermutlich bekannteste Projekt der OWASP. Seit 2003 veröffentlicht das Top 10 Projekt, basierend auf den Daten von hunderten Organisationen weltweit, eine priorisierte Liste von Schwachstellen/Risiken und möglichen Gegenmassnahmen.
Seit Dezember 2019 veröffentlich das API Security Projekt der OWASP auch eine Top 10 Liste. Nicht dass API Security in der bekannten Top 10 Liste gefehlt hätte, aber OWASP trägt dem Umstand Rechnung, dass die Bedeutung von Schnittstellen und speziell auch REST Schnittstellen im mehr zugenommen hat und darum ein eigenständiger Bedrohungs- und Massnahmenkatalog gerechtfertigt ist.
Überblick über die Top Ten API Schwachstellen
Die folgende Tabelle zeigt die vollständige Liste der API Schwachstellen gemäss OWASP:
Nummer | Titel | Beschreibung |
API1 | Broken Object Level Authorization | APIs neigen dazu, Endpunkte freizulegen, die Objektidentifikatoren verarbeiten, was zu einer großen Angriffsfläche für die Zugriffskontrolle führt. Berechtigungsprüfungen auf Objektebene sollten bei jeder Funktion berücksichtigt werden, die über die Eingabe des Benutzers auf eine Datenquelle zugreift. |
API2 | Broken Authentication | Authentifizierungsmechanismen sind oft falsch implementiert, so dass Angreifer Authentifizierungstoken kompromittieren oder Implementierungsfehler ausnutzen können, um vorübergehend oder dauerhaft die Identitäten anderer Benutzer zu übernehmen. Wenn die Fähigkeit des Systems, den Client/Benutzer zu identifizieren, beeinträchtigt wird, wird die API-Sicherheit insgesamt beeinträchtigt. |
API3 | Excessive Data Exposure | Mit Rücksicht auf sehr allgemeine Nutzung von APIs, neigen Entwickler dazu, alle Attribute von Objekten offenzulegen, ohne Rücksicht auf deren individuellen Schutzbedarf. Sie verlassen sich darauf, dass Clients die Daten filtern, bevor sie dem Benutzer angezeigt werden. |
API4 | Lack of Resources & Rate Limiting | Häufig beinhalten APIs keine Einschränkungen in Bezug auf die Größe oder Anzahl der Ressourcen, die vom Client oder Benutzer angefordert werden können. Dies kann sich nicht nur auf die Leistung des API-Servers auswirken, was zu Denial of Service (DoS) führt, sondern auch die Tür für Authentifizierungsfehler wie Brute Force offen halten. |
API5 | Broken Function Level Authorization | Komplexe Zugriffskontrollrichtlinien mit unterschiedlichen Hierarchien, Gruppen und Rollen sowie eine unklare Trennung zwischen administrativen und regulären Funktionen führen tendenziell zu Berechtigungsfehlern. Durch die Ausnutzung dieser Probleme erhalten Angreifer Zugang zu den Ressourcen und/oder Verwaltungsfunktionen anderer Benutzer. |
API6 | Mass Assignment | Die Bindung von vom Kunden bereitgestellten Daten (z.B. JSON) an Datenmodelle, ohne eine geeignete Filterung der Eigenschaften auf der Grundlage einer Whitelist, führt in der Regel zu einer Massenzuordnung. Das Erraten von Objekteigenschaften, das Erkunden anderer API-Endpunkte, das Lesen der Dokumentation oder das Bereitstellen zusätzlicher Objekteigenschaften in Anforderungs-Payloads ermöglicht es Angreifern, Objekteigenschaften zu ändern, die sie nicht ändern sollen. |
API7 | Security Misconfiguration | Fehler in der Konfiguration der Sicherheit ist in der Regel das Ergebnis unsicherer Standardkonfigurationen, unvollständiger oder ad-hoc-Konfigurationen, offener Cloud-Speicher, falsch konfigurierter HTTP-Header, unnötiger HTTP-Methoden, permissiver Cross-Origin Resource Sharing (CORS) und ausführlicher Fehlermeldungen mit sensiblen Informationen |
API8 | Injection | Injection Fehler, wie SQL, NoSQL, Command Injection, etc. treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Befehls oder einer Anfrage an einen Interpreter gesendet werden. Die bösartigen Daten des Angreifers können den Interpreter dazu bringen, unbeabsichtigte Befehle auszuführen oder ohne entsprechende Berechtigung auf Daten zuzugreifen. |
API9 | Improper Assets Management | APIs neigen dazu, mehr Endpunkte zu veröffentlichen als herkömmliche Webanwendungen, was eine korrekte und aktualisierte Dokumentation sehr wichtig macht. Ein ordnungsgemäßer Bestand an Hosts und bereitgestellten API-Versionen spielt ebenfalls eine wichtige Rolle, um Probleme wie veraltete API-Versionen und exponierte Debug-Endpunkte zu reduzieren. |
API10 | Insufficient Logging & Monitoring | Unzureichende Protokollierung und Überwachung, gepaart mit fehlender oder ineffektiver Einbindung in die Gefahrenabwehr, ermöglichen es Angreifern, ihre Angriffe zu intensivieren, sich tiefer einzunisten und ihre Angriffe aus andere Systeme auszudehnen. Alles mit dem Ziel Daten zu manipulieren, zu extrahieren oder zu zerstören. Die meisten Studien zeigen, dass die Zeit bis zur Feststellung einer Verletzung mehr als 200 Tage beträgt, was in der Regel eher von externen Parteien als von internen Prozessen oder der Überwachung erkannt wird. |
OWASP API Security 2019 vs. Top Ten 2017
Vergleicht man die neue Top Ten Liste für API Security mit der aktuellen für Web-Applikationen aus dem Jahr 2017 (A1-A10), stellt man sehr rasch fest, dass einige Schwachstellen in vergleichbarer Form und zum Teil auch mit ähnlicher Gewichtung auf beiden Listen aufzufinden sind:
- Broken Authentication: API2 ist identisch zu A2
- Excessive Data Exposure: API3 ist ähnlich zu A3
- Security Misconfiguration: API7 ist vergleichbar zu A6
- Injection: API8 ist identisch, aber unterschiedliche priorisiert zu A1
- Insufficient Logging & Monitoring: API10 ist identisch zu A10
Dies ist nicht weiter erstaunlich, denn die Gemeinsamkeiten von traditionellen Webseiten oder Portalen mit Applikationen die REST Schnittstellen nutzen sind sehr gross. Die Applikationen verfolgen den gleichen Zweck und auch die verwendeten Technologien sind sehr eng miteinander verwandt. Die Applikationen müssen auch die gleichen Probleme lösen, zum Beispiel die Authentisierung von Benutzern, die Autorisierung der Datenzugriffe, die Persistenz von Daten, das Deployment in der Cloud oder im Rechenzentrum, das Schreiben von Logs oder die Einbettung in Monitoring Systeme.
Viel spannender als die grossen Gemeinsamkeiten sind die Unterschiede. Das Thema Injection wird zwar bezüglich Inhalt auf beiden Listen geführt, aber die Beurteilung der Priorität ist doch recht unterschiedliche. Eine mögliche Erklärung kann sein, dass die für REST genutzten Tools praktisch flächendeckend eingesetzt werden und diese bereits sehr viele Probleme im Bereich der Validierung von Inputdaten, ohne weiteres Zutun des Entwicklers, lösen. Solche Tools waren in den Anfängen der traditionellen Webapplikationen viel weniger ausgereift und darum ist auch heute noch das Risiko für traditionelle Web-Applikationen höher einzuschätzen. Was gegen diesen Erklärungsansatz spricht ist der Umstand, dass injection grundsätzlich im API selbst verhindert werden muss, denn ein API kann sich ja nicht auf den Schutz durch "wohlgesonnene" Clients verlassen.
Eine Bedrohung, welche scheinbar für APIs nicht gilt, ist die XML External Entities (XXE) Schwachstelle. Es liegt nahe, dass die Autoren der API Security Risks vor allem REST Schnittstellen im Fokus haben, denn SOAP Webservices werden im Bereich mobiler Applikationen oder bei SPAs im Browser praktisch nicht eingesetzt. Auch Cross Site Scripting (XSS) fehlt in der API Security Risks Liste. Es ist zwar korrekt, dass XSS in erster Linie ein Browser Problem ist und APIs selbst keine JavaScript interpretieren, aber APIs könnten JavaScript übermitteln und so in XSS involviert werden. Vermutlich sind die Autoren davon ausgegangen, dass die Inputvalidierung der API8 auch JSP Injection verhindert und darum XSS als eigenständiges Risiko unnötig ist.
API Security spezifische Risiken
Die API Security Top 10 identifiziert auch Risikien die sich ausschliesslich auf REST APIs beziehen. Im speziellen wird "Broken Access Control" (A5 der Top 10) sehr viel detaillierter und auch viel höher gewichtet. Mit API1, API3 und API6 sind 3 Risiken identifiziert worden, die alle einen starken Bezug zu A5 haben. API1 umfasst Risiken welche die Zugriffsautorisierung auf Objekt-Ebene durch manipulierte Identifier fokussieren, API3 befasst sich mit dem Auslesen von Daten direkt an der API selbst und API6 beschreibt die Risiken der Manipulation von Attributen von Objekten wenn diese ungewollt exponiert werden.
Mit API4 (Lack of Resource & Rate Limiting) und API9 (Improper Asset Management) wird dem Umstand Rechnung getragen, dass es viel mehr APIs gibt und diese auch sehr viel direkter exponiert sind. Business Logik und Daten werden nicht durch Webserver oder Portale abgeschottet und das erfordert zusätzliche Massnahmen, damit die Risiken in diesem Bereich reduziert werden können.
Massnahmen zum Schutz von APIs
Aufbau einer Security Infrastruktur
Die Verwendung spezialisierter Sicherheitskomponenten um exponierte Schnittstellen zu schützen gilt heute als Best Practice. Diese Aussage gilt unabhängig davon, ob die spezialisierten Sicherheitskomponenten an der Peripherie des Firmennetzwerks ihren Dienst tun, ob im Sinne einer Zero Trust Architektur, jede einzelne Schnittstelle durch eigene Sicherheitskomponenten geschützt wird oder ob ein Hybrider Ansatz zum Zug kommt.
Für die Umsetzung kann aus einer Vielzahl von Produkten ausgewählt werden, aber im Grundsatz müssen immer folgende Funktionen abgedeckt werden:
- Web Application Firewall für den Schutz von Webseiten und Portalen
- API Gateway für den Schutz von REST Schnittstellen
- Identity und Access Management für die Access Control zu Webseiten, Portalen und Schnittstellen
Airlock vereint diese 3 Komponenten in einem zentralisierten Secure Access Hub.
Je nach Hersteller kann es Abweichungen geben, wie die Architektur im Detail umgesetzt wird, weil die Anzahl Komponenten und auch die Verteilung von Funktionen auf die Komponenten im Detail unterschiedlich realisiert sein kann. Für die Zielsetzung, die Risiken der OWASP API Security zu reduzieren, ist das aber nicht entscheidend. Entscheidend ist, dass die verschiedenen Funktionen im ausgewählten Produkt umgesetzt und korrekt konfiguriert sind (API7).
Die Angriffsoberfläche kann bereits substantiell eingeschränkt werden, weil nur die API auch wirklich exponiert werden, die von extern auch erreichbar sein sollen (API9). So wird vermieden, dass Interfaces die für den ausschliesslich internen Gebrauch vorgesehen sind, unnötig exponiert werden.
Ist eine OpenAPI Spezifikation verfügbar, dann kann der API Gateway die Zugriffe auf explizit für die Veröffentlichung spezifizierte Funktionen einschränken (API9) und auch eine formale Input-Validierung der übermittelten Parameter vornehmen (API8).
Bereits im API Gateway können Rate Limits durchgesetzt werden (API4) ohne dass die eigentliche Business Logik oder die Daten Persistenz überhaupt mit überzähligen Requests belästigt wird. In vielen Produkten sind die Policies dabei so umgesetzt, dass auch komplexe Business Modelle unterstützt werden können, die abhängig vom Benutzer andere Limiten durchsetzen.
Identity und Access Management Systeme stellen sicher, dass Benutzer angemessen authentisiert sind (API2). Moderne IAM Systeme, wie von Airlock, unterstützen Standards with OAuth, OpenID Connect oder SAML und propagieren so die verifizierte Identität der Benutzer zu den Applikationen und APIs (API5). Airlock IAM erlaubt zusätzlich die Umsetzung von Single-Sign-On über mehrere Applikationen und stellt User Self-Services Funktionen zur Verfügung.
Beide Systeme, API Gateway und IAM, erzeugen sowohl technische als auch fachlichen Log Output, der idealerweise in einem SIEM System gesammelt und analysiert wird (API10).
Pflichten für Entwickler
Der aufmerksame Leser hat bereits gemerkt, dass nicht alle API Risiken mit vorgelagerten Sicherheitskomponenten adressiert werden können, weil Business Regeln nur in der Business Logik der Schnittstelle bekannt sind und darum auch nur dort durchgesetzt werden können. Die Frage, ob ein gewisser User wirklich zugreifen darf auf ein spezifisches Business Objekt, kann nur in der Business Logik der Applikation beantwortet werden (API1) aber auch im Zusammenhang mit API3 und API6 sind Entwickler in der Pflicht ihre APIs so zu entwerfen, dass nur die notwendigen Informationen exponiert werden und nur das erlaubt wird, was erlaubt sein soll.
Als Software Entwickler sollte man sich aber darüber im klaren sein, dass sichere Software nur dann entsteht, wenn während der Entwicklung berücksichtigt wird, dass die Software auch ohne vorgelagerte Sicherheitskomponenten bedenkenlos eingesetzt werden kann. "Security by Design" ist ein Gebot, dass speziell bei der Entwicklung von APIs befolgt werden sollte.
Zusammenfassung
Die Liste der OWASP API Security Risks ist das Resultat der zunehmenden Bedeutung von REST Schnittstellen und es ist die logisch konsequente Weiterführung der OWASP Top 10 Liste. Zunehmende Bedeutung führt aber auch zu zunehmender Bedrohung, weil APIs bereits heute aber auch in Zukunft vermehrt angegriffen werden. Geeignete Sicherheitskomponenten (Secure Access Hub: Web Application Firewall, API Gateway, Identity und Access Management Systeme) können helfen um die Risiken zu reduzieren, aber auch die Entwickler sind in der Pflicht um den sicheren Umgang mit der Business Logik und den Daten sicher zu stellen.
Der Secure Access Hub von Airlock bietet sicheren Schutz vor den OWASP API Security Risks und vor den OWASP Top 10. Entdecken Sie die Vorteile und weitere Funktionen vom Airlock Secure Access Hub und lesen Sie den im Heise Magazin veröffentlichten Fachartikel, um mehr über die neue OWASP Top 10 Liste, die Hintergründe und Verantwortlichkeiten zu erfahren.
Blognews direkt in Ihr Postfach
Der Airlock Newsletter informiert Sie laufend über neue Blogartikel.