Mit APIs ist es wie mit Telefonen: Es gibt sie schon geraume Zeit, doch in den letzten Jahren haben sie sich radikal verändert. Und wer sich bei ihrer Absicherung heute auf die gleichen Tools verlässt wie vor zehn oder zwanzig Jahren, dürfte sich jede Menge Schwierigkeiten einhandeln. Hier eine kurze Geschichte der APIs und was diese in den Cloud-nativen, Microservices-basierten und containerisierten Umgebungen von heute leisten müssen.
Wer die Cyberszene über einen längeren Zeitraum hinweg beobachtet, wird feststellen, dass die Cyberkriminellen den Fokus ihrer Angriffe immer weiter ausdehnen: Nahmen sie früher in erster Linie angreifbare Anwender, Prozesse und Technologien ins Visier, reichen ihre Attacken heute weit über diese »klassischen« Ziele hinaus. So gut wie nichts ist mehr vor ihnen sicher – und auch wenn die Unternehmen immer wieder Fortschritte bei der Absicherung ihrer Systeme machen: Sobald ein Angriffsvektor erfolgreich geschlossen wird, finden die Angreifer binnen kürzester Zeit eine neue Lücke.
Heute fokussieren sich die Cyberkriminellen zunehmend auf APIs, die sich mehr und mehr zum neuen Angriffsperimeter entwickelt haben. Tatsächlich legen aktuelle Studien den Schluss nahe, dass APIs bis 2022 der häufigste Vektor für Angriffe auf Webanwendungen in Unternehmen sein werden. Dies liegt in erster Linie daran, dass die Zahl der API-Implementierungen weltweit rasant zunimmt – und den Angreifern damit ein Angriffspunkt zur Verfügung steht, der noch weitgehend unerforscht ist. Es wird also immer wichtiger, APIs besser zu verstehen und zuverlässig zu schützen.
Das Konzept der API Security ist dabei zwar relativ neu, die Angriffe sind es jedoch nicht: Die meisten Unternehmen sind seit vielen Jahren mit ganz ähnlichen Threats vertraut, auch wenn sich diese bislang eher gegen ihre Netzwerke und ihre Internet-basierten Anwendungen richteten. Nun müssen sie sich darauf einstellen, dass die gleichen oder ähnliche Attacken auch ihre mobilen Apps, ihre APIs und ihre Back-End-Server ins Visier nehmen. Bevor wir aber im Detail darüber sprechen, welche Gefahren heute mit APIs einhergehen, müssen wir erst verstehen, was sie so einzigartig und angreifbar macht.
API-basierte vs. klassische Anwendungen. API-basierte Apps unterscheiden sich ganz grundsätzlich von klassischen Anwendungen: Wenn Anwender/Besucher früher über ihren Browser auf eine Webseite zugriffen, erfolgte der Großteil der Datenverarbeitung auf dem Webserver selbst. Mit der steigenden Vielfalt der Gerätemodelle – und auch mit deren zunehmender Rechenleistung, dem immer größeren Speicher und der höheren Bandbreite – verlagerte sich die Logik in den letzten Jahren aber immer mehr von den Back-End-Servern auf das Front-End (also auf den Client selbst), während der Downstream-Server mehr und mehr zum Proxy für die Daten der API-basierten App wurde.
Heute sind APIs eine Kernkomponente jeder modernen Anwendungslandschaft, und leisten weitaus mehr, als lediglich Third-Party-Daten in Anwendungen einzuspeisen: Die meisten modernen Microservices verlassen sich auf interne APIs, um einander zu identifizieren und miteinander zu kommunizieren. Wenn diese Kommunikation gestört wird, kann dies also durchaus dazu führen, dass die gesamte Anwendung nicht mehr funktioniert.
Auch bei der Bereitstellung einer Container-Anwendung über eine Orchestrierungsplattform wie Kubernetes sind wir heute auf funktionierende APIs angewiesen, die die verschiedenen Einzelteile des Clusters koordinieren – die Worker Nodes, die Master Nodes, die Pods, die Sidecars und all die anderen.
Und auch das Deployment skalierbarer Anwendungen in der Cloud erfordert leistungsfähige APIs, um das Management der Anwendungen zu automatisieren, den Traffic zu steuern und vieles mehr. Technisch gäbe es dabei zwar durchaus Alternativen, in der Praxis haben sich API-zentrierte Ansätze aber als das effizienteste Modell erwiesen.
APIs sind also überall, und ohne sie wäre ein effizienter IT-Betrieb undenkbar. Doch die Frage nach der Sicherheit ist damit nach wie vor offen. Wie verwundbar sind APIs denn nun?
Welche Gefahren mit APIs einhergehen. Bedauerlicherweise sind APIs von vielen Seiten angreifbar, und die Herausforderungen bei der Absicherung API-basierter Anwendungen bewegen sich auf einem ähnlichen Level wie bei ihren browserbasierten Counterparts. Erschwerend kommt hinzu, dass bei API-basierten Attacken auch die darunter liegende Implementierung der Mobile-App kompromittiert werden kann, dass in der Regel auch der User-Status über die Client-App verwaltet und überwacht wird und dass in jedem http-Request deutlich mehr Parameter übermittelt werden (Object IDs, Filter u.v.m.) – die Security-Herausforderungen der APIs sind also in mancher Hinsicht einzigartig. Letzten Endes lassen sich die daraus resultierenden Schwachstellen in der Regel in drei Kategorien einordnen:
- Offenlegung oder Verlust sensibler Daten.
- Kompromittierung der Kommunikationsflüsse.
- Möglichkeit zu Denial-of-Service-Attacken auf Backend-Server.
All das führt dazu, dass es immer wichtiger wird, die APIs durchgehend zu sichern und zu managen – wobei keine API wie die andere ist: Wenn ein Problem mit einer API lediglich verhindert, dass Ihre App auf einen Third-Party-Service zugreift, ist das ärgerlich – aber die Core-Funktionalitäten der App werden aller Voraussicht nach weiterhin funktionieren, und wahrscheinlich werden Sie einfach nur kurze Zeit auf einige sekundäre Funktionen verzichten müssen – etwa die Möglichkeit, Kontaktlisten aus Social-Media-Accounts zu beziehen. Etwas vollkommen anderes ist es, wenn diejenigen APIs ausfallen, auf die Ihre Microservices angewiesen sind, oder – noch schlimmer – wenn die APIs über keine angemessene Access Control verfügen und somit sensible interne Anwendungsdaten an nicht vertrauenswürdige Endpoints übergeben werden. In diesen Szenarien werden Ihre Anwendungen womöglich gar nicht mehr bereitstehen, und vielleicht sind sogar kritische Daten gefährdet.
Aus diesem Grund müssen Entwickler heute in der Lage sein, das Design, das Management und die Security der APIs durchgehend zu überwachen. Die Teams müssen genau wissen, was APIs leisten können und was nicht. Sie müssen Zugriffe auf granularem Level managen, um sicherzustellen, dass ihre APIs jedem Software-Service genau die benötigten Ressourcen zur Verfügung stellen, aber nicht mehr. Und schließlich müssen sie Daten zum Verhalten der APIs erfassen und auswerten, um Anomalien, die auf einen Angriff hinweisen könnten, frühzeitig zu entdecken.
Die OWASP API Security Top 10. Um die Sicherheit der APIs zu gewährleisten und Awareness für deren Risikopotenzial zu schaffen, hat die OWASP bereits 2019 eine eigene Top-10-Liste der gefährlichsten API-Security-Bedrohungen entwickelt. Die regelmäßig aktualisierte Liste umfasst aktuell die folgenden Risiken:
- Lack of object-level authorization checks.
- Flawed user authentication.
- Exposure of more data than necessary.
- Lack of resource quotas or limits.
- Flawed function authorization.
- Lack of filtering for client data.
- Reliance on default security configurations or configurations that are flawed.
- Injection attacks.
- Insufficient tracking of exposed resources.
- Insufficient monitoring.
Entwickler, die gewährleisten möchten, dass ihre Apps und APIs im Sinne einer Security-by-Design auch ohne vorgelagerte Security-Systeme zuverlässig geschützt sind, erhalten mit der OWASP-Liste eine exzellente Ausgangsbasis für die Ableitung und Implementierung robuster Secure Coding Practices.
Entsprechende Leitfäden und Templates sind heute aus unterschiedlichsten renommierten Quellen verfügbar, und wer sich konsequent an den entsprechenden Richtlinien orientiert, kann das Security-Standing seiner APIs und seiner Apps nachhaltig steigern.
Das heißt aber nicht, dass die OWASP-Liste vollumfänglich wäre. Nach dem heutigen Stand der Technologie gibt es durchaus Bereiche, die in den Top 10 bislang nur am Rande Erwähnung finden – und denen Unternehmen nach heutigen Maßstäben tendenziell mehr Aufmerksamkeit widmen sollten. Hierzu gehören:
- Third-Party APIs: Die OWASP unterscheidet nach aktuellem Stand nicht zwischen internen APIs und Third-Party-APIs. Auch wenn beide Varianten in technologischer Hinsicht weitgehend identisch funktionieren, gehen externe APIs mit höherem Risikopotenzial einher, da sich das Monitoring (und in vielen Fällen auch das Management der Authentisierung und Autorisierung) wesentlich schwieriger gestaltet. Entwickler sind also gut beraten, Third-Party-APIs besondere Aufmerksamkeit zu widmen.
- Monitoring: Die Überwachung der API-Ressourcen und des API-Verhaltens wird in der OWASP Top 10 lediglich relativ kurz in den beiden Schlussabsätzen erwähnt. Nach heutigem Security-Verständnis wird dies dem hohen Stellenwert des Monitorings und Loggings schlichtweg nicht gerecht – denn ohne lückenlose Transparenz über die APIs ist kein nachhaltiges Risikomanagement möglich. Entwickler sollten diesen Aspekt daher zumindest in Gedanken definitiv höher auf der Liste ansetzen.
- Training und Security-Kultur: Man kann der OWASP sicher nicht vorwerfen, dass sie nicht um den Stellenwert des Lernens und Schulens wüsste – in der Top-10-Liste bleibt das Thema aber tatsächlich unerwähnt. Dabei ist gerade beim Thema API Security, das an der Schnittstelle zwischen den Dev- und den Security-Teams angesiedelt ist, eine enge Collaboration und ein offener Wissensaustausch von zentraler Bedeutung. Unternehmen sollten dies bei ihren Initiativen berücksichtigen.
Fazit: Sicherheit in einer API-gesteuerten Welt. APIs sind eine Schlüsseltechnologie im modernen Software-Stack. So sehr, wie wir auf funktionierende APIs angewiesen sind, können wir es uns schlichtweg nicht leisten, dass diese zum existenziellen Risiko werden. Die Entwickler müssen daher lernen, die Sicherheit der APIs in den Fokus ihrer Arbeit zu stellen und durch die konsequente Einhaltung von Secure Coding Practises die Weichen für eine konsequente Security-by-Design zu stellen. Die OWASP Top-10-Liste der API-Security-Bedrohungen ist ein hervorragender Ausgangspunkt für die entsprechenden Initiativen – wobei die Verantwortlichen in einigen Bereichen gut beraten sind, punktuell über die Empfehlungen hinaus zu gehen.
Dr. Christopher Brennan zeichnet
als Regional Director für die DACH- und
CEE-Region beim Application-Security-
Anbieter Checkmarx verantwortlich.