Drei Dinge, die jeder CISO über API-Sicherheit wissen sollte

Chuck Herrin

In der dritten Folge von F5 Global CISO: Von Verteidigern für Verteidiger, war Corey Ball, einer meiner liebsten API-Hacker, bei mir zu Gast. Corey ist seit 15 Jahren in der IT und Cybersicherheit tätig und hat buchstäblich das Buch über das Hacken von APIs geschrieben, nachdem er festgestellt hatte, dass es zu diesem Thema kaum gebündeltes Wissen gab. Damals lernten wir uns auch kennen.

Das Buch trägt den Titel „Hacking APIs: Breaking Web Application Programming Interfaces“ und bietet einen Crashkurs zu Sicherheitstests für Web-APIs. Corey war außerdem Mitbegründer der APIsec University, einer kostenlosen Lernplattform für API-Sicherheit, und ist Gründer und CEO von hAPI Labs, einem Unternehmen, das Sicherheitstests für APIs und Penetrationstests für Webanwendungen durchführt.

Jetzt anhören

Hör dir die neuesten Folgen meines Podcasts an:

• Folge 3: „API-Sicherheit im KI-Zeitalter“
• Folge 4: „Vereinfachen und absichern: die wichtigsten Cybersicherheitsstrategien für Führungskräfte“

Corey ist eindeutig ein Experte für API-Sicherheit. Deshalb stellte ich ihm die Frage des Tages: Welche drei Dinge sollte jeder CISO über API-Sicherheit wissen? Insbesondere wollte ich erfahren, was Verteidiger seiner Meinung nach lernen können, wenn sie API-Sicherheit aus der Perspektive eines Angreifers betrachten.

Tipp 1: Testen Sie Ihre Tools für API-Sicherheitstests

APIs sind die Technologie, die hinter der Übertragung von Daten steht – einer der wertvollsten Ressourcen der Welt. „Doch während wir zum Schutz dieser Daten mehrere Verteidigungsebenen wie Firewalls und Web Application Firewalls einrichten“, so Corey, „können über das Internet erreichbare APIs Angreifern häufig als Einfallstor dienen.“ Eine ungesicherte API, die weder eine Authentifizierung verlangt noch eine Autorisierung durchsetzt, kann Kriminellen direkten Zugang verschaffen. Sie können darüber unbefugte Anfragen stellen und die Daten stehlen, die durch all die anderen Sicherheitsebenen geschützt werden.

„Ich möchte sicherstellen, dass die für die Abwehr Verantwortlichen verstehen, dass sie die richtigen Tools und Methoden einsetzen müssen, um die Sicherheit ihrer APIs zu testen“, sagte er. Es reicht nicht aus, einfach einen automatisierten Scanner auf eine API anzusetzen, einen unauffälligen Bericht zu erhalten und davon auszugehen, dass alles sicher ist. Die Verantwortlichen müssen API-Anfragen aktiv testen und analysieren, um echte Schwachstellen aufzudecken und vorhandene Sicherheitsprobleme zu beheben.

Testen Sie Ihre Tester. Eine praktische Möglichkeit, Testkompetenzen und -tools zu überprüfen, besteht Corey zufolge darin, an absichtlich verwundbaren Anwendungen zu üben. Dabei handelt es sich um sichere, speziell entwickelte Ziele, anhand derer Tester häufige Arten von API-Sicherheitsproblemen erleben, reproduzieren und verstehen können. „Zum Beispiel bietet das OWASP API Security Project crAPI an, ein Schulungstool, das absichtlich zahlreiche API-Schwachstellen enthält und speziell für das Lehren, Lernen und praktische Üben von API-Sicherheit entwickelt wurde. Sie können Ihren Scanner direkt auf crAPI ansetzen und sehen, welche Ergebnisse Sie erhalten.“ Wenn nur oberflächliche Schwachstellen gefunden werden, etwa fehlende HSTS-Header oder falsch konfigurierte Clickjacking-Schutzmaßnahmen, übersieht Ihr Testtool möglicherweise schwerwiegendere API-Schwachstellen, beispielsweise solche aus den OWASP API Top 10. „Dies würde zeigen, dass Ihre Testtools möglicherweise nicht so effektiv sind, wie Sie denken“, so Corey.

Tipp 2: WAFs und API-Gateways reichen zum Schutz von APIs nicht aus

Corey und ich sprachen auch darüber, dass klassische Schwachstellen-Tools und -Managementprogramme für Unternehmen bei APIs nicht funktionieren, da APIs für andere Arten von Angriffen anfällig sind als herkömmliche Webanwendungen. Beispielsweise sind eine fehlerhafte Autorisierung auf Objektebene (Broken Object Level Authorization, BOLA) und eine fehlerhafte Autorisierung auf Ebene der Objekteigenschaften (Broken Object Property Level Authorization, BOPLA) API-Sicherheitslücken, die mit der zentralen Geschäftslogik der API zusammenhängen. Ich fragte Corey: Wenn ein Unternehmen eine WAF und ein API-Gateway implementiert hat, was fehlt dann noch beim Schutz seiner APIs?

WAFs und API-Gateways sind für die Anwendungssicherheit und die Benutzerauthentifizierung von entscheidender Bedeutung, sagte er, reichen allein jedoch nicht aus, um APIs zu schützen. Die größte Herausforderung bei der Absicherung von APIs ist die Autorisierung, also sicherzustellen, dass Benutzer nur auf ihre eigenen Daten zugreifen, sie einsehen, ändern oder löschen können. „Sie müssen sicherstellen, dass Benutzer A nur mit den Ressourcen von Benutzer A interagieren kann. Er darf die Ressourcen von Benutzer B weder ändern noch lesen, aktualisieren oder löschen“, sagte er. „Die Autorisierung in APIs ist definitiv eine Herausforderung. Die Anfrage eines kriminellen Angreifers nach den Ressourcen einer anderen Person sieht einer legitimen Anfrage sehr ähnlich, sofern keine granularen Autorisierungsregeln vorhanden sind.“

Autorisierungskontrollen müssen Teil eines mehrschichtigen Ansatzes für die API-Sicherheit sein, der mehrere sich ergänzende Kontrollen kombiniert, sodass bei Ausfall einer Schutzebene die anderen weiterhin Schutz bieten.

Tipp 3: Die Absicherung generativer KI erfordert zusätzliche Schutzmaßnahmen

Da Unternehmen zunehmend in generative KI und KI-gestützte Anwendungen investieren, müssen sie sich darüber im Klaren sein, dass diese Technologien die API-Angriffsfläche vergrößern. Das liegt daran, dass Anwendungen mit generativer KI durch und durch auf APIs basieren. Mit anderen Worten: Eine Welt der KI ist eine Welt der APIs. Die zugrunde liegende Struktur generativer KI-Anwendungen stützt sich in hohem Maße auf APIs, und nahezu jeder Teil des KI-Systems ist über diese Schnittstellen zugänglich.

Doch wie Corey und ich erörtert haben, sind APIs nur ein Teil der Herausforderung bei der Absicherung von KI-Anwendungen und -Architekturen: Auch KI-Engines und große Sprachmodelle (LLMs) weisen weitere Schwachstellen auf, die Angreifer ausnutzen können. Das Model Context Protocol (MCP) beispielsweise ist ein Open-Source-Standard, der ein einheitliches Framework für die Anbindung von LLMs an externe Tools und Dienste bereitstellt. MCPs bieten zwar viele Vorteile für die Integration von KI in Anwendungen, bringen jedoch auch erhebliche Sicherheitsrisiken mit sich. „Wenn man hinter die Kulissen generativer KI blickt“, so Corey, „sieht man, dass sie bereits aus einer Vielzahl von APIs besteht. Dann kommen noch MCPs hinzu, die aufgrund schwacher Authentifizierungs- und Autorisierungskontrollen häufig anfällig sind – auch wenn die Sicherheitsmaßnahmen allmählich aufholen.“

Ein weiterer Sicherheitsaspekt bei MCPs sind Prompt-Injection-Angriffe und das Hacken mittels natürlicher Sprache. „Diese können zu Geschäftsrisiken führen, wenn KI-Agenten und Chatbots Ihr Unternehmen repräsentieren. Angreifer können Ihre KI-Agenten dazu bringen, etwas Anstößiges zu sagen, das Ihr Unternehmen in ein schlechtes Licht rückt, oder Chatbots dazu überreden, unberechtigte Rabatte zu gewähren.“ Unternehmen müssen sich außerdem darüber im Klaren sein, dass Chatbots als rechtliche Vertreter des Unternehmens gelten können und das Unternehmen für ihre Aussagen und Handlungen rechtlich haftbar gemacht werden kann. Unternehmen müssen daher umsichtig vorgehen: Sie wollen die Geschäftschancen, die KI-Apps bieten, nicht verpassen, müssen aber zugleich mit der gebotenen Sorgfalt sicherstellen, dass KI-Apps und Chatbots mit korrekten Daten trainiert und gegen Prompt-Injection-Angriffe abgesichert sind.

Es ist immer wieder eine Freude, mich mit Corey auszutauschen, und ich möchte ihm dafür danken, dass er mit mir darüber gesprochen hat, was Verteidiger lernen können, wenn sie Sicherheit aus der Perspektive eines Angreifers betrachten. Als Verteidiger müssen wir unsere Abwehr an den Angriffsmethoden ausrichten. Daher müssen wir alle verstehen, wie Angriffe funktionieren und wonach diese Akteure suchen, damit wir unsere begrenzten Ressourcen gezielt für eine mehrschichtige Verteidigung einsetzen können, die für Ihr Unternehmen, Ministerium oder Ihre Behörde sinnvoll ist.

Ihre zentrale Anlaufstelle, um Bedrohungen immer einen Schritt voraus zu sein

Mein vollständiges Gespräch mit Corey Ball können Sie sich hier ansehen.

Jetzt abonnieren und keine Folge von „The Global CISO: Für Verteidiger, von Verteidigern“ auf Ihrer bevorzugten Podcast-Plattform verpassen – und teilen Sie sie mit Ihrem Team, Ihren Kollegen und Ihrem Netzwerk.

Und wie immer gilt: Wenn es Themen gibt, die Sie gerne behandelt sehen würden, schreiben Sie mir bitte eine Nachricht oder vernetzen Sie sich mit mir auf LinkedIn.

Über den Autor

Chuck Herrin

Weitere Blogbeiträge von Chuck Herrin