Software auf Sicherheit testen
Unsicheren APIs auf der Spur
Moderne Web-Anwendungen setzen auf Microservices. APIs halten sie zusammen. Je modularer und größer die Anwendung, desto mehr APIs. Das wird schnell unübersichtlich und kann Sicherheitslücken aufreißen. Sicherheitstest-Tools (IAST, Interactive Application Security Testing) können Entwicklern helfen.
Moderne (Web-)Anwendungen verwenden Software-Architekturen, die auf sogenannten Microservices aufbauen. Also auf vielen kleinen Programmen, die sich auf jeweils eine oder sehr wenige Funktionen beschränken. Jedes Programm läuft dabei in seinem eigenen Container. Dadurch wird die Gesamtanwendung skalierbar, da diese Programme (Microservices) dynamisch repliziert, ausgetauscht oder auf mehr oder weniger leistungsfähige Hardware-Knoten verschoben werden können – ganz nach aktuellem Bedarf. Die Infrastruktur dafür liefern Container-Management-Werkzeuge wie Kubernetes.
Diese Mini-Programme tauschen Daten und Informationen über Webschnittstellen, sogenannte REST APIs (Representational State Transfer Application Programming Interface), aus. Die geringe Komplexität der einzelnen Microservices und die Kommunikation über definierte Schnittstellen ermöglichen eine gute Testbarkeit und begünstigen so eine schnelle und agile Software-Entwicklung. Komplexe Webapplikationen bestehen mitunter aus hunderten und tausenden solcher Microservices. Genau das stellt Security- und Compliance-Teams oft vor große Herausforderungen.
Jobangebote+ passend zum Thema
Ein Haus mit vielen Türen
Eine der größten Herausforderungen ist, dabei die Übersicht nicht zu verlieren. Welche Schnittstellen sind »von außen« direkt oder indirekt zugänglich? Welche Schnittstellen »nach außen« gibt es, die z.B. externe oder sogar öffentliche Dienste verwenden, wie etwa APIs von Google, GitHub oder Facebook.
Gerade letztere werden aus Security-Sicht häufig als weniger wichtig erachtet, da es sich zum einen »nur« um ausgehende Verbindungen handelt, und zum anderen die APIs von Google oder Microsoft sehr hohen Sicherheitsstandards unterworfen sind. Trotzdem lauern hier durchaus noch weitere Risiken.
Der erste Schritt, um wieder die Oberhand zu gewinnen, ist die Katalogisierung aller Schnittstellen. Hier ist Automatisierung unabdingbar, da Software-Entwickler sonst bei der Entwicklungsgeschwindigkeit nicht mithalten können oder das Entwicklungsteam unter Umständen sogar ausbremst wird. An dieser Stelle sind Standards wie etwa OpenAPI [1] sinnvoll, unterstützt von entsprechenden Tools, um den Code nebst Dokumentation, Tests und so weiter automatisch zu generieren. Das erleichtert es zudem, Sicherheit und Lizenzkonformität zu überprüfen.
Eine solche Katalogisierung ist vergleichbar mit der Inventur der verbauten Open-Source-Software- Komponenten – also der Erstellung einer Software Bill-of-Materials, SBOM. Nur geht es hier eben nicht um Komponenten, sondern um APIs.
Klopf, klopf, herein? – Eingangs-APIs
Empfangende APIs, also Schnittstellen der Anwendung, die von außen zugreifbar sind, sind oft das größte Sicherheitsrisiko. Diese Risiken dürften in keinem Bedrohungsmodell (Threat Model) fehlen, das die Grundlage für entsprechende Maßnahmen in der Softwarearchitektur und Implementierung bildet.
Schwieriger wird es bei Schnittstellen von »internen« Microservices, die nur indirekt von außen erreichbar sind. Datenpakete (Payloads), die für den einen Microservice harmlos sind, können in einem anderen durchaus Schaden anrichten. Daher ist es wichtig, den Datenfluss zwischen den einzelnen Microservices innerhalb der Gesamtanwendung zu verstehen und bei Sicherheitstests entsprechend zu berücksichtigen. Das ist aber gar nicht so einfach, und die Klassiker unter den Testmethoden, DAST (Dynamic Application Security Testing) und SAST (Static Application Security Testing), unterstützen dieses Vorgehen in der Regel nicht.
DAST oder Penetration-Testing-Werkzeuge arbeiten in der Regel als Black Box, d.h. mit ihnen lässt sich nur ein kleiner Teil der möglichen Datenflüsse abdecken. Ähnliches gilt für API-Fuzzing. All diesen Methoden ist gemein, dass eine hohe Abdeckung nur mit einem hohen Zeitaufwand erreicht werden kann. Deshalb lassen sie sich in der agilen Entwicklung nur bedingt einsetzen.
SAST wäre grundsätzlich gut geeignet, da es sich um White-Box-Tests handelt, das Tool somit die Anwendung besser versteht und sich außerdem hervorragend automatisieren lässt. Leider arbeiten SAST-Tools nicht über die Grenzen von Microservices hinweg, sie verstehen folglich den Datenfluss innerhalb der Gesamtanwendung nicht. Dadurch greift eine der größten Stärken von SAST, die Datenflussanalyse, bei Microservices-basierten Architekturen ins Leere.
Das Interactive Application Security Testing, kurz IAST, kombiniert Black-Box- und White-Box-Tests. IAST ist ein relativ junges Mitglied in der Riege der AST-Werkzeuge (Application Security Testing) neben den Platzhirschen SAST und DAST, die seit vielen Jahren im Markt etabliert sind. IAST wird bisher meist als ein Spezial-Tool angesehen. Der große Vorteil dieser Methode: IAST pflanzt sogenannte Agenten in die einzelnen Microservices, wodurch es den Datenfluss durch die Gesamtanwendung »sieht« und auch Zugriff auf Laufzeitdaten der einzelnen Microservices hat, wie z.B. OpenAPI-Daten aus dem Speicher.
Tools wie beispielsweise Seeker von Synopsys nutzen sowohl statische Daten (OpenAPI Spezifikation) als auch dynamische Methoden (API Scraping) um alle möglichen Empfangs-APIs aufzulisten und nachfolgend zu analysieren. Letzteres beinhaltet das gezielte Testen auf Sicherheitsmängel. Eine anschließende aktive Verifikation mit entsprechenden, schädlichen Datenpaketen schließt False Positives aus.
Quo Vadis? – Ausgangs-APIs
Ausgangs-APIs sind aus Sicht eines einzelnen Microservice fremde Schnittstellen, die von diesem Microservice verwendet werden, also vergleichbar dem Aufrufen einer Website über einen Browser. Demgegenüber können empfangende Programmierschnittstellen etwa so betrachtet werden wie ein auf dem eigenen Rechner betriebener Web- oder FTP-Server.
Ziel-APIs für ausgehende Aufrufe können hierbei die Eingangs-APIs benachbarter Microservices sein – was der Regelfall sein dürfte – oder aber öffentliche APIs – oder zumindest applikationsfremde APIs –, um z.B. Wetter- oder Standortinformation abzurufen, oder einen Dienst wie Google Translator zu nutzen.
Diese APIs sind eher selten ein Sicherheitsrisiko – können also im Normalfall nicht kompromittiert werden. Aber ihre Verwendung unterliegt oft gewissen Lizenzbedingungen, ganz ähnlich Open-Source-Lizenzen wie GPL (GNU General Public License) oder MIT (Massachusetts Institute of Technology). Werden solche APIs unwissentlich verwendet und die damit verbundenen Lizenzbedingungen implizit akzeptiert, kann das weitreichende Konsequenzen haben und zu signifikanten Geschäftsrisiken führen.
Was also tun?
Aufgrund der genannten Risiken kommen immer mehr API-Scanner auf den Markt, die sich dieser Problematik anzunehmen versuchen. Der Einsatz solcher Scanner ist in einem agilen Entwicklungsumfeld aber nur dann sinnvoll, wenn der Scanner gut in die CI-Pipeline integrierbar ist und die Ergebnisse für Entwickler direkt verwertbar sind.
Bei der Auswahl sollte berücksichtigt werden, welche Risiken damit adressiert werden. Dazu ist es hilfreich zu verstehen, ob es sich um statische oder dynamische Analyse-Tools handelt und wie Schwachstellen und Lizenzen ermittelt werden. Folgende Fragen helfen bei der Auswahl:
- Wird ein Katalog von allen API-Endpoints erstellt? Für Eingänge oder auch Ausgänge? Für Eingangs-APIs – also bereitgestellte APIs: werden Spezifikationen wie z.B. OpenAPI unterstützt?
- Gibt es eine grafische Darstellung, z.B. einen Datenflussgraph mit Microservices, Verbindungen und Protokollen (siehe Bild 2)?
- Ist die Darstellung und Beschreibung der Schwachstelle aus Entwicklersicht nachvollziehbar? Gibt es Quellcodeauszüge, Stack Traces, und/oder andere kontextsensitive Informationen?
- Wie wird auf Schwachstellen in Eingangs-APIs geprüft?
- Welche Information zu öffentlichen APIs gibt es? Wie umfangreich ist die entsprechende Datenbank von öffentlichen APIs?
- Wie und wo findet die Integration in die CI-Pipeline statt?
- Wird auf verwendete Open-Source-Software-Komponenten und bekannte Schwachstellen (CVE, Common Vulnerabilities and Exposures) hin geprüft? Wird beispielsweise erkannt, ob Log4j in Version 2.14 verwendet wird?
SAST, DAST und IAST im Vergleich
Microservices-basierte Anwendungen erfreuen sich aufgrund der schnellen Entwicklung und guten Skalierbarkeit großer Beliebtheit. Ihre schnell wachsende Zahl und die der damit verbundenen Schnittstellen lassen einen Software-Entwickler schnell die Übersicht verlieren, insbesondere was Risiken bezüglich Sicherheit und Compliance angeht.
Neben den von der Anwendung bereitgestellten APIs sollte ein Software-Entwickler auch auf externe APIs achten (Ausgangs-APIs), da ihre Verwendung gegebenenfalls unerwünschten Lizenz- oder Nutzungsbedingungen unterworfen ist.
Traditionell eingesetzte SAST- und DAST-Werkzeuge sind nur bedingt geeignet. IAST-Werkzeuge schlagen die Brücke zwischen DAST und SAST (siehe Tabelle) und integrieren idealerweise sogar Software Composition Analysis (SCA), um einen Katalog mit Microservices und den damit verbundenen Risiken zu erstellen. Synopsys beispielsweise hat in der letzten Generation seines IAST-Tools Seeker die DAST-Technik von Tinfoil und die SCA-Technik von Black Duck integriert.
| SAST | DAST | IAST | |
|---|---|---|---|
| Testmethode | White Box | Black Box | White Box |
|
Entwicklungsphase(n) |
Entwicklung | Qualitätssicherung, Produktivbetrieb | Integration, Qualitätssicherung |
| Voraussetzung/Einsatzgebiet | Quellcode | Lauffähige Anwendung | Lauffähige Anwendung mit Test-Suite |
| CI/CD-Integration | ++ | – | ++ |
| Genauigkeit1 | – | + | ++ |
| Behebbarkeit der Fehler | ++ | – | + |
| Testabdeckung | + | + | +2 |
| Unterstützte Fehlerarten | + | + | + |
| Findet Laufzeit-/Betriebsfehler | Nein | Ja | Ja |
| Unterstützte Programmiersprachen/Techniken | + | ++ | / |
| Besondere Unterstützung für Microservices | Nein3 | Nein | Ja4 |
| Anmerkungen | Keine lauffähige Anwendung notwendig | Läuft als Teil der QS-Tests (kein separater Scan nötig) | |
|
1 Gemessen an False-Positives Häufigkeit 2 Abhängig von der Abdeckung durch Test-Suite 4 Erkennt Microservices und deren Zusammenhang; ggf. Visualisierungsfunktionen ++ sehr gut + gut / zufriedenstellend – schlecht –– sehr schlecht |
|||
Tabelle. Vergleich von SAST, DAST und IAST. Durch die verschiedenen Anwendungsbereiche sowie Stärken und Schwächen ergänzen sich die Methoden. (Quelle: Synopsys)
Literatur
[1] OpenAPI Specification. SmartBear Software, Website, https://swagger.io/specification/
Der Autor
Gunnar Braun
ist Technical Account Manager bei Synopsys und unterstützt große Unternehmen bei der Erstellung von sicherer Software. Er beschäftigt sich seit 20 Jahren mit Werkzeugen für die Software-Entwicklung und hat sich von Compilerbau und der Simulation von eingebetteten Systemen bis hin zu Webanwendungen »hochgearbeitet«. Seit vier Jahren konzentriert er sich auf den Bereich Software-Sicherheit, mit Fokus auf Integration von Werkzeugen in agile Entwicklungsprozesse.
Lesen Sie mehr zum Thema
