Offen für Entwickler, sicher vor Hackern

APIs (Application Programming Interfaces, Anwendungsprogrammierschnittstellen) ermöglichen die Integration vielfältiger Anwendungen, Systeme und Datenbestände. Sie bilden die Grundvoraussetzung für die App Economy. Neben der höheren Agilität bieten sie Unternehmen den Vorteil, auf bekannter Technik und existierender Infrastruktur aufzubauen. Damit APIs nicht zu einem Sicherheitsrisiko werden, benötigen sie einen besonderen Schutz.

Was mit COM+, CORBA oder SOAP nur unzureichend geschaffen wurde, ist durch APIs möglich: Entwickler können leicht offene Infrastrukturen schaffen, um Funktionen und Daten über Applikationen hinweg zu nutzen. Gut realisierte APIs sind so transparent, dass ein entsprechend ausgebildeter Entwickler durch die Überprüfung der URL, Eingabeparameter und die aufgerufenen Inhalte (Returned Content) die API intuitiv zu nutzen weiß. APIs vermitteln transparent die Logik des zugrunde liegenden Implementierungsmusters einer Anwendung - Details, die sonst unter den vielen Schichten der App-Funktionalität liegen würden.

Diese Vereinfachung ist für den Entwickler ein Segen, kann aber für Unternehmen zum Fluch werden: Sie mindert auch den Aufwand für Hacker und lässt sie Angriffe einfacher umsetzen. APIs machen interne Strukturen von Backend-Systemen und Client-Anwendungen transparent und dadurch leichter angreifbar. Sie verschieben Filter, die die Zugriffsmöglichkeiten von Anwendungen auf die Backend-Systeme steuern, von der relativ sicheren internen Ebene auf eine außerhalb liegende Client-Anwendung - ein Schritt, der die Angriffsfläche für Hacker erheblich vergrößert.

Die offene Struktur, die APIs auszeichnet, ist also ohne geeigneten Schutz ein Risiko. Damit APIs kein Einfallstor für Kriminelle öffnen, muss man diese Schnittstellen vor Gefahren aus dem Internet und vor den unterschiedlichen Arten von Angriffsvektoren schützen. Die meisten Hacker nutzen verschiedenste Techniken und Prinzipien, um eine Anwendung über eine API zu infiltrieren. Zur Verbesserung der Sicherheit sollten mindestens die drei gängigsten dem Entwickler bekannt sein und bei der Programmierung von APIs Berücksichtigung finden.

Im Internet sind Parameter indirekt, die Möglichkeiten der Datenverarbeitung sind limitiert. Bei APIs dagegen ist die Parametrierung viel expliziter, sie legen größere Teile von HTTP offen. Parameterangriffe zielen häufig auf Webstrukturen ab und folgen meist einem gleichen Schema: Durch geeignete Dateneingaben verschaffen sich Hacker Zugriff auf eine Anwendung und die zugrundeliegende Datenstruktur wie URL, Abfrageparameter und HTTP-Header. APIs sind deshalb immer dann gefährdet, wenn ihr Entwickler - der an Web-Frameworks gewöhnt ist - die Prüfung von Dateneingaben vernachlässigt.

Risiko Parameter

Bekannt sind bereits unterschiedliche Parameter-Angriffsformen: Bei der Script Insertion werden Systeme, die übermittelte Parameterinhalte auswerten, als Skript genutzt - zum Beispiel, wenn ein JavaScript-Schnipsel in den Beitrag eines Webforums eingesetzt wird. Bei SQL Injections werden Parameter, die für das Laden von Input in eine Datenbank entwickelt wurden, so manipuliert, dass sie die Programmierung eines zugrunde liegenden SQL-Templates verändern. Bei Bound- oder Buffer-Overflow-Angriffen lassen Hacker Systeme abstürzen, indem sie einen anderen Typ oder ein Übermaß an Daten in das System laden.

Gegen Parameterattacken auf APIs gibt es Sicherheitsstrategien, die das Angriffsrisiko verringern: Der effektivste Schutz besteht darin, alle Daten, die eine API passieren, auf Gültigkeit und Unbedenklichkeit zu überprüfen. Dazu sind strikte Schemata durch Typisierung, Ranges und Sets aufzusetzen, die erlaubte Dateneingaben definieren und ankommende Daten auf ihre Zulässigkeit untersuchen. Blacklists werden damit durch Whitelists ersetzt, die durch ihre Konfiguration das Manipulationsrisiko mindern.

Automatisch und über verschiedene Entwickler-Tools generierte Schemata reduzieren Parameter auf grobe Modelle, mit denen aber Gefahren nicht sicher erkennbar sind, sodass zur Umsetzung dieser Logiken Eigenentwicklung den Vorrang haben sollte. Um in einem Schema auch XML-basierte Content-Typen zu berücksichtigen, kann man dieses mit der XML Schema Language aufsetzen, mit der sich Modelle und Strukturen von unerwünschten Inhalten effektiv umsetzen lassen. Für die immer stärker verbreiteten JSON-Dateitypen gibt es entsprechende JSON-Sprachen zur Schemabeschreibung. JSON ist im Aufbau weniger komplex als XML - mit einer Transparenz, die das Umsetzen einer Sicherheitsstrategie erleichtert und letztlich für einen besseren Schutz sorgt.

Identitäten

Die Authentifizierung verläuft im Internet meist relativ einfach durch eine Kombination aus Benutzername und Passwort. Bei APIs ist die Lage komplizierter, da mehrere Identitäten miteinander interagieren - sowohl Geräteidentitäten als auch Identitätsebenen wie die Nutzer-Login-Daten für unterschiedliche Apps und Websites oder Gerätekennzahlen. Zusätzliche Komplexität bringen API Keys, die einer Client-Anwendung eine eindeutige Identität zuweisen und eine Art Zugangscode sind, um auf die Funktionen von Anwendungen zugreifen zu können. Durch APIs wird bei einer Anfrage zwar die jeweilige Anwendung identifiziert, jedoch nicht der Nutzer oder einzelne Instanzen einer Anwendung. Diese Vielschichtigkeit macht APIs anfällig für identitätsbasierte Angriffe, die Schwachstellen in der Authentifizierung, Autorisierung und beim Session-Tracking ausnutzen.

Deshalb darf man Praktiken der Webentwicklung nicht auf die Realisierung von APIs übertragen. Ein Sicherheitsrisiko lässt sich vermeiden, wenn API Keys nicht anstelle von Benutzerinformationen zum Einsatz kommen. API Keys sollten auch nicht als Autorisierungs-Tracking-Mechanismus Verwendung finden, weil sie keine Nutzeridentitäten erkennen und häufig in Server-Protokollen sichtbar und in URLs integriert sind. Hacker können API Keys einfach erkennen, da diese sich nicht wie ein Passwort sicher auf dem Client speichern lassen. Schlechtes Session-Management gibt identitätsbasierten Angriffen zusätzlich Spielraum, da manche Web-Entwickler zu nachlässig im Einsatz von Formation Credentials bei einzelnen Transaktionen sind oder ganz eigene Methoden hierfür einsetzen.

Um identitätsbasierten Angriffen vorzubeugen, sollte man HTTPS als grundlegende Voraussetzung für ein sicheres API-Management ganzheitlich einsetzen. HTTPS stellt die Integrität aller Daten her, die zwischen Client und Server ausgetauscht werden, und bietet zudem die Möglichkeit einer Authentifizierung auf Client-Seite.

Die Nutzeridentitäten und Anwendungen sind getrennt voneinander zu implementieren. Die Einführung von Prozessen strenger Authentifizierung, die sich auf Kriterien wie IP-Adresse, Zugriffsdauer auf ein Fenster, Geräteidentifikation bei mobilen Apps oder Ortsbestimmung stützen, ist unverzichtbar. Entwickler sollten API Keys nur für die Anwendung selbst einsetzen, und zwar ohne dass API Keys, Passwörter und Session-IDs in der URL erscheinen.

Man in the Middle

MITM-Angriffe (Man in the Middle) sind gefürchtet, weil der Angreifer dabei jeweils die Identität des anderen Kommunikationspartners simuliert, um unbemerkt in den Datenverkehr einzugreifen. Der E-Mail-Versand kritischer Codes und Tokens wie API Keys, OAuth- und JSON-Web-Tokens erleichtert es MITM-Angreifern, in Anwendungen einzudringen. Vernachlässigt ein Programmierer zudem das Lifecycle-Management und ignoriert bewährte Methoden für ein sicheres Key-Management, vereinfacht dies Manipulationen.

Der konsequente Schutz von APIs und der API-Datenverkehr durch gut konfigurierte SSL-Verbindungen reduziert die möglichen Angriffspunkte für Hacker und ist daher unabdingbar. Hardware-Sicherheitsmodule schützen kritische API Keys zusätzlich. Bei der Entwicklung von API-Sicherheit ist der Einsatz bewährter Methoden zuverlässiger, als PKIs (Public Key Infrastructures) neu zu erfinden.

Die beste Lösung für ein sicheres API-Management besteht darin, die Implementierung und den Schutz der APIs voneinander zu trennen, da man so die richtige Expertise zur richtigen Zeit heranzieht. Entwickler konzentrieren sich ausschließlich auf die Konfiguration der API und gewährleisten, dass sie Anwendungen, Systeme und Daten miteinander verbindet. Sicherheitsexperten sind verantwortlich für den Schutz von Parametern, Identitäten und Daten. Die Verbindung von Kompetenzen und die Konzentration auf Stärken minimiert Risiken und reduziert Angriffsspielräume.

Lesen Sie mehr zum Thema