Open-Banking

Schlecht gesicherte APIs machen Open-Banking zum Risiko

, München, Radware

Schlecht gesicherte APIs machen Open-Banking zum Risiko

Absicherung von Open-Banking-APIs

Von Thomas Hertel, IT-Fachjournalist

Schlecht gesicherte APIs stellen global eines der größten Risiken für die Open-Banking-Initiative dar. Öffentlich zugängliche APIs zwischen den Anwendungen von Banken und FinTechs bilden das Rückgrat des Open Banking, das einen nahtlosen Austausch von Kundendaten zwischen solchen Unternehmen vorsieht, sofern der Kunde zustimmt. Open-Banking-APIs sollen einerseits dem Kunden mehr Möglichkeiten bei der Auswahl von Finanzdienstleistern und andererseits diesen neue Umsatzpotentiale und Kollaborations-Möglichkeiten eröffnen.

Die Open-Banking-Initiative wird in erster Linie durch die europäische Regulierung Payment Services Directive 2 (PSD2) vorangetrieben, um geschlossene und proprietäre Kundendaten von Banken, die Einlagen entgegennehmen, über öffentlich verfügbare APIs sicher für externe Drittanbieter (Third Party Providers – TPPs) zu öffnen. Ziel ist es, sowohl die Innovation zu fördern als auch den Wettbewerb zu stärken.

Im Gegensatz zum traditionellen Bankwesen, bei dem alle Kundendaten von der Mutterbank kontrolliert werden, werden beim Open Banking die Kundendaten über Anwendungs-Programmierschnittstellen (APIs) sicher an TPPs weitergegeben, sofern der Kunde sein Einverständnis gegeben hat. Hier liegt allerdings ein erhebliches Sicherheitsproblem: Gartner prognostiziert, dass Angriffe auf APIs schon im Jahr 2022 der häufigste Angriffsvektor sein werden, der Datenschutzverletzungen bei Webanwendungen von Unternehmen verursacht. Die Herausforderung der API-Sicherheit erfordert eine umfassende Abdeckung aller Bedrohungen, eine einfache Integration und die vollständige Sichtbarkeit sowohl dokumentierter als auch undokumentierter APIs.

Open-Banking-APIs – was könnte schiefgehen?

Vor der Einführung von Open Banking nutzten viele innovative FinTech-Anbieter Screen Scraping, um ohne Wissen der Mutterbank Zugang zu Kundendaten einschließlich der Benutzerdaten zu erhalten. Open-Banking-APIs sollen die rechtlichen Auswirkungen der gemeinsamen Nutzung von Kundendaten und -informationen durch APIs, die Zustimmung dazu und die Arbeit der Aufsichtsbehörden vereinfachen. APIs bringen zwar enorme Vorteile mit sich, führen aber auch zu erheblichen Bedenken bezüglich der Verfügbarkeit und der Sicherheit:

  • Service-Unterbrechung: Nichtverfügbarkeit von API-Diensten aufgrund von Sicherheits-, Netzwerk- und Anwendungskonfigurationsfehlern, API-Denial-of-Service-Angriffen oder Ausfällen der Anwendungs- oder Authentifizierungs-Infrastruktur.
  • Fehlendes Vertrauen: Viele Lösungen für Open Banking basieren auf einer reinen Cloud- oder Hybrid-Infrastruktur. Die Migration zu öffentlichen Clouds führt jedoch zu Vertrauensproblemen aufgrund der Inkompatibilität von Sicherheitslösungen, Konfigurationsproblemen in verschiedenen Umgebungen, Fehlkonfigurationen und Problemen mit Anwendungssicherheits-Richtlinien und -profilen.
  • Vergrößerte Angriffsfläche: API-Angriffe verschiedener Art sind relativ häufig. Eine Umfrage von Radware ergab, dass 55 % der Unternehmen mindestens einmal im Monat einen DoS-Angriff auf ihre APIs erleben, 48 % mindestens einmal im Monat eine Form von Injektionsangriff und 42 % mindestens einmal im Monat eine Manipulation von Elementen/Attributen. Zu den weiteren Angriffen gehören API-Authentifizierungs- und Autorisierungs-Angriffe, eingebettete Angriffe wie SQL-Injection, Cross-Site Scripting (XSS) und Bot-Angriffe.
  • Bot-Angriffe auf APIs: Bei Bot-Angriffen handelt es sich um automatisierte Programme mit Skripten, die in Benutzerkonten eindringen, Identitäten stehlen, Zahlungsbetrug begehen, Inhalte, Preise, Gutscheine oder Daten abgreifen, Spam oder Propaganda verbreiten und Geschäftsaktivitäten beeinträchtigen.
  • Datendiebstahl: Viele APIs verarbeiten sensible personenbezogene Daten (PII). Die Kombination aus sensiblen und vertraulichen Informationen in Verbindung mit der mangelnden Transparenz der Funktionsweise dieser APIs und Anwendungen von Drittanbietern ist im Falle eines Verstoßes ein Alptraum für die Sicherheit.
  • Nicht dokumentierte, aber veröffentlichte APIs: Nicht dokumentierte APIs können versehentlich sensible Informationen preisgeben, wenn sie nicht getestet werden, und sie können offen für API-Manipulationen und die Ausnutzung von Sicherheitslücken sein.

API-Gateways und WAFs reichen nicht aus

Da die Bedrohungen unterschiedlich sind, erfordert die API-Sicherheit eine Kombination von Sicherheitskontrollen, darunter:

  • API-Zugangskontrollen für Authentifizierung, Autorisierung und Zugangsverwaltung
  • Schutz vor übermäßigen Berechtigungen
  • Schutz vor BOT-Angriffen auf APIs
  • Verhinderung von Denial-of-Service-Attacken
  • Schutz vor eingebetteten Angriffen, API-Schwachstellen und API-Manipulationen
  • Verhinderung des Abflusses von PII-Daten und der übermäßigen Offenlegung von Daten
  • Schutz vor Betrug und Phishing

Traditionell sind DDoS-Schutz, WAFs und API-Gateways die primären Sicherheitstools, die für den API-Schutz eingesetzt werden. Während API-Gateways die Möglichkeit der API-Verwaltung bieten und eine Integration mit Authentifizierungs- und Autorisierungs-Funktionen bieten, sind ihre Funktionen für API-Sicherheit, Bot-Schutz und Webanwendungsschutz entweder begrenzt oder nicht vorhanden. Die meisten WAFs verstehen die Unterschiede zwischen APIs und normalen Webanwendungen nicht. Und selbst wenn sie den Unterschied verstehen, können sie die tatsächlichen Sicherheitsrisiken im Zusammenhang mit APIs nicht untersuchen oder erkennen.

Bots sind nicht immer freundlich oder sichtbar

Auch APIs sind Bot-Angriffen ausgesetzt. Nach Angaben von Forrester stammen mehr als ein Viertel aller Webanfragen von bösartigen Bots. Diese Bots versuchen automatisierte Angriffe auf APIs, beispielsweise Kontoübernahme, Missbrauch von Zahlungsdaten und Denial-of-Inventory. Auch DDoS-Angriffe auf Anwendungen werden über APIs ausgeführt, um die Infrastrukturen von Banken und Finanzdienstleistern zu überlasten. Solche Angriffe werden mit ausgeklügelten, menschenähnlichen Bots durchgeführt, die über Tausende von IP-Adressen und Geräte-IDs verteilt sind und von herkömmlichen Sicherheitssystemen nur sehr schwer erkannt und abgewehrt werden können. Diese Angriffe führen zu einer Verlangsamung und Nichtverfügbarkeit wichtiger Anwendungen und Dienste, was für Kunden und Unternehmen eine frustrierende Erfahrung ist.

Der Schutz von APIs vor automatisierten Angriffen unterscheidet sich von dem Schutz von Web- und Mobilanwendungen, einfach weil das Verhalten der Bots, der Navigationsfluss und die Indikatoren unterschiedlich sind. Das Fehlen spezieller Bot-Management-Tools in den meisten Unternehmen erhöht das Risiko, dass Hacker erfolgreiche Angriffe über APIs starten, wie z. B. Credential Stuffing, Brute Force und Scraping-Versuche. API-Gateways bieten zwar API-Verwaltung und Integration mit Authentifizierungs- und Autorisierungsfunktionen, aber ihre Funktionen für API-Security, Schutz vor Bots und Anwendungssicherheit sind entweder begrenzt oder nicht vorhanden. Andererseits verstehen die meisten WAFs die Unterschiede zwischen APIs und normalen Webanwendungen nicht. Und selbst wenn sie das tun, können sie die tatsächlichen Sicherheitsrisiken im Zusammenhang mit APIs nicht untersuchen oder erkennen. Es ist daher zwingend erforderlich, weitere Maßnahmen zu ergreifen, um die Sicherheitsrichtlinien für dokumentierte und undokumentierte APIs durchzusetzen.

Um APIs zu sichern, muss eine WAAP-Lösung (Web Application and API Protection) alle dokumentierten und undokumentierten APIs erkennen und API-Aufrufe blockieren, die einen der folgenden Verletzungsindikatoren versuchen:

  • Zugriff auf eingeschränkte APIs
  • Verwendung nicht definierter oder nicht zulässiger HTTP-Methoden für einen API-Endpunkt
  • Nicht erkannte und ungültige Parameter
  • Parameterwerte, die außerhalb des erwarteten Bereichs liegen
  • Einbettung von Webangriffen in JSON-Payloads oder -Parameter
  • Exzessive Nutzung der APIs
  • Extrahieren sensibler Daten über das API
  • Versuch der Ausnutzung von API-Schwachstellen
  • Versuch, den API-Authentifizierungsprozess durch einen Kontoübernahmeangriff zu umgehen

Absicherung von Open-Banking-APIs

Um APIs in Open-Banking-Umgebungen abzusichern, kombiniert Radware unterschiedliche Technologien und Lösungen sowie positive und negative Sicherheitsmodelle.

  • DDoS-Schutz: Die On-Premise-Lösung DefensePro oder der Cloud DDoS-Schutzdienst schützen vor sich entwickelnden Cyber-Bedrohungen mit umfassendem, automatisiertem DDoS-Schutz, der sich kontinuierlich anpasst, um die möglichst schnelle Erkennung und Abwehr von Bedrohungen zu ermöglichen.
  • Cloud Security Posture Management (CSPM) und Cloud Infrastructure Entitlement Management (CIEM) : Radwares Cloud Native Protector (CNP) sichert die Cloud-Umgebung gegen Identitäts- und Zugriffsmissbrauch, schützt vor bösartigem Benutzerverhalten und sichert die gesamte Sicherheitslage der Public Cloud-Umgebung.
  • Reverse Proxy oder Application Delivery Controller (ADC) : Die Alteon Multi-Cloud-Lösung ermöglicht es Unternehmen, Benutzerverbindungen von Anwendungen zu entkoppeln, um diese individuell zu skalieren und dabei sowohl die Zugriffslatenz als auch die Betriebskosten für die Skalierung von Anwendungen zu reduzieren.
  • WAAP: Die WAAP-Lösung von Radware ist integriert mit Alteon (integrierte WAF), als Managed Cloud-Service (CWAF) oder als Lösung in Kubernetes-Umgebungen (KWAF) erhältlich, um eine einfache Integration mit gängigen Tools für Softwarebereitstellung, Test und Visibility in der CI/CD-Pipeline zu ermöglichen.
  • Bot Manager: Der Radware Bot Manager verteidigt APIs gegen automatisierte Angriffe und stellt sicher, dass nur legitime Benutzer und Geräte auf die APIs zugreifen können, und blockiert jeden Reverse-Engineering-Versuch. Er nutzt eine umfassende Verhaltensanalyse hinter einer API-Anfrage, um bösartige Aktivitäten zu blockieren.

Fazit

Obwohl das Open Banking noch in den Kinderschuhen steckt, wächst es sehr schnell. Open Banking öffnet Kundendaten für externe Drittanbieter über APIs, um innovative Dienste anzubieten. Dies bedeutet jedoch auch eine größere Angriffsfläche, die vor Missbrauch und Böswilligkeit geschützt werden muss. Banken und FinTechs, die in diesem Umfeld erfolgreich sein wollen, werden Lösungen anbieten müssen, die das Vertrauen der Kunden durch sichere Anwendungen fördern.