So machen Sie API-Sicherheitstests zu einem automatisierten Teil des CI-Prozesses

Wie automatisiert man API-Tests , um sie skalierbar und nachhaltig zu gestalten? Lesen Sie weiter, um die Antwort auf diese und weitere Fragen zu erhalten.

Da Penetrationstests teuer sind und lange dauern können, müssen wir API-Sicherheitstests auf skalierbare und nachhaltige Weise durchführen.

Die Diskussion über API-Sicherheit und warum wir uns darum kümmern sollten, ist ein bisschen so, als würde man über den Verzehr unseres Gemüses sprechen. Wir alle wissen, dass der Verzehr unseres Gemüses gut für unsere Gesundheit ist, aber wie viele von uns tun es tatsächlich? Anwendungssicherheit ist ein bisschen so. Obwohl es für die Gesundheit unserer Anwendungen und unseres Unternehmens unerlässlich ist, ist das Streben danach bei weitem nicht so interessant wie das Erstellen cooler neuer Anwendungsfunktionen. Aber wir müssen uns nur die jüngsten Schlagzeilen ansehen, um zu verstehen, wie wichtig sie sind.

Traditionell wurde die Überprüfung einer Anwendung oder API auf Sicherheit am Ende des Entwicklungsprozesses durchgeführt. Dies ist jedoch von Natur aus problematisch. In der Regel ist es zu spät, um festgestellte Fehler zu beheben: Möglicherweise liegt das Veröffentlichungsdatum zu nahe, um die Probleme zu beheben, oder das Team ist zu anderen Projekten übergegangen, oder die Architektur der Anwendung ist von Natur aus unsicher.

Zudem werden Dienste und Anwendungen heutzutage häufiger denn je veröffentlicht, oft sogar mehrmals täglich. Dieser schnelle Release-Zyklus macht den traditionellen Ansatz untragbar. In diesem Blog stelle ich eine schrittweise Checkliste für API-Sicherheit vor , mit der sich API-Sicherheitstests zu einem automatisierten Bestandteil des CI-Prozesses machen lassen.

Geben Sie Continuous Integration ein

Um dieses Problem zu lösen, greifen wir auf eine Lösung zurück, die in der Branche bereits erfolgreich zur Bewältigung von Softwarequalitätsproblemen bei beschleunigten Releasezyklen eingesetzt wird: Continuous Integration. Continuous Integration erstellt Builds, sobald neuer Code eingecheckt wird, und validiert diesen durch statische Codeanalyse und Unit-Tests für jeden Build . Fortgeschrittene Teams erstellen und führen mithilfe von CI sogar automatisierte Funktionstests aus (möglicherweise nicht für jeden Build, da Funktionstests in der Regel lange dauern, aber zumindest in festgelegten Intervallen, beispielsweise einmal täglich).

Wir können dieselbe Lösung auf automatisierte Sicherheitstests für unsere APIs anwenden, indem wir Penetrationstests in unsere CI-Workflows integrieren. Dies stellt sicher, dass wir früher auf Sicherheitsschwachstellen testen, und wir erhalten Sicherheitsregressionstests, mit denen neue Probleme sofort erkannt werden können, sobald sie eingeführt werden. Aber wir müssen klug vorgehen, da Penetrationstests teuer sind und lange dauern können. Wir müssen dies auf skalierbare und nachhaltige Weise tun.

Beginnen Sie mit Funktionstests

Ich gehe davon aus, dass unsere Teams bereits automatisierte Funktionstests für unsere APIs schreiben und ausführen . (Falls dies nicht der Fall ist, müssen wir damit beginnen und können die Automatisierung unserer Sicherheitstests noch nicht in Betracht ziehen.) Wenn wir automatisierte Funktionstests für unsere APIs durchführen, können wir im Rahmen unserer regulären Entwicklungs- und Qualitätssicherungsprozesse eine Teilmenge dieser Funktionstests als Sicherheitstests identifizieren. Diese Teilmenge werden wir dann als Sicherheitstests vorbereiten und ausführen.

Ich möchte Ihnen anhand von Parasoft SOAtest und dessen integrierter Unterstützung für Penetrationstests , die in der Version 2021.2 enthalten ist, erläutern, wie dies funktioniert.

Nehmen wir zunächst an, wir haben ein SOAtest-Szenario mit 1 Setup-Test, der die Datenbank bereinigt, und 3 Tests, die 3 verschiedene API-Aufrufe durchführen. Wir möchten Penetrationstests für jede der 3 APIs durchführen, die im Szenario aufgerufen werden:

Wir bereiten das Szenario zunächst auf Sicherheit vor, indem wir jedem der Tests im Szenario ein Penetrationstest-Tool hinzufügen:

Anschließend führen wir dieses Szenario mit SOAtest durch. Bei jedem Testlauf führt SOAtest den im Test definierten API-Aufruf durch und erfasst den Anfrage- und Antwortverkehr. Das Penetrationstest-Tool übergibt die Verkehrsdaten bei jedem Test an eine eingebettete Instanz des OWASP ZAP Penetrationstest-Tools. Dieses führt anhand der in den Verkehrsdaten beobachteten API-Parameter und unter Anwendung eigener Heuristiken einen Penetrationstest der API durch.

Das Penetrationstest-Tool meldet dann alle gefundenen Fehler im Zusammenhang mit dem Test, der auf die API zugegriffen hat. Hier ist ein SOAtest-Beispielbericht mit allen Fehlern, die nach CWE und nach Schweregrad geordnet sind:

SOAtest-Ergebnisse können für zusätzliche Berichtsfunktionen weiter in DTP, dem Berichts- und Analyse-Dashboard von Parasoft, gemeldet werden. Hier ist eine Darstellung, wie das funktioniert:

Die Wiederverwendung von Funktionstests zur Verwendung als Sicherheitstests bietet die folgenden Vorteile:

1. Da wir bereits Funktionstests schreiben, können wir bereits geleistete Arbeit wiederverwenden, was Zeit und Mühe spart.
2. Um bestimmte APIs auszuführen, müssen wir möglicherweise einige Einstellungen vornehmen, z. B. das Vorbereiten der Datenbank oder das Aufrufen anderer APIs. Wenn wir mit Funktionstests beginnen, die bereits funktionieren, ist dieses Setup bereits abgeschlossen.
3. In der Regel meldet ein Penetrationstest-Tool, dass ein bestimmter API-Aufruf eine Sicherheitsanfälligkeit aufweist, gibt jedoch keinen Kontext über den Anwendungsfall und / oder die Anforderung an, mit der er verbunden ist. Da wir SOAtest zum Ausführen der Testfälle verwenden, werden die Sicherheitslücken im Kontext eines Anwendungsfalls gemeldet. Wenn Szenarien mit Anforderungen verknüpft wurden, können wir jetzt zusätzlichen Geschäftskontext über die Auswirkungen der Sicherheitsfehler auf die Anwendung abrufen.
4. Wir haben ein Testszenario, mit dem wir den Fehler einfach reproduzieren oder überprüfen können, ob er behoben wurde.

Vorbereiten von Funktionstests zur Verwendung als Sicherheitstests

Bei der Wiederverwendung von Funktionstests zur Verwendung als Penetrationstests sind einige Dinge zu beachten:

1. Wir sollten unsere funktionalen Testszenarien getrennt von unseren Sicherheitstestszenarien pflegen und sie von separaten Testjobs aus ausführen. Der Hauptgrund dafür ist, dass das Hinzufügen von Penetrationstests zu bestehenden Funktionstests wahrscheinlich dazu dient, die Funktionstests zu destabilisieren. Wir müssen auswählen, welche funktionalen Testszenarien in automatisierte Sicherheitstests umgewandelt werden sollen, und dann Kopien der funktionalen Tests erstellen, die als separate Sicherheitstests verwaltet werden.
2. Wir müssen bei den Tests wählerisch sein, da Penetrationstests teuer sind; Wir müssen die Angriffsfläche der abgedeckten API maximieren und gleichzeitig die Anzahl der Tests minimieren. Folgendes sollten wir bedenken:
   • Penetrationstest-Tools analysieren den Anforderungs- / Antwortverkehr, um zu verstehen, welche Parameter in der Anforderung zum Testen verfügbar sind. Wir müssen Funktionstests auswählen, die alle Parameter in jeder API ausführen, um sicherzustellen, dass jede Eingabe in die API analysiert wird.
   • In jedem Szenario müssen wir entscheiden, welche API-Aufrufe einem Penetrationstest unterzogen werden sollen. Auf dieselbe API kann von mehreren Szenarien aus verwiesen werden, und wir möchten keine Penetrationstests für eine API duplizieren, die in einem anderen Szenario getestet wird. Das Penetrationstest-Tool sollte nur zu den entsprechenden Tests für die zu testenden API(s) hinzugefügt werden.
   • Die Anzahl der Szenarien muss überschaubar sein, damit der Sicherheitstestlauf kurz genug ist, um mindestens einmal am Tag zu laufen.

3. Unsere Funktionstestszenarien können Abschnitte zum Einrichten oder Herunterfahren zur Initialisierung oder Bereinigung enthalten. Diese müssen normalerweise nicht auf Penetration getestet werden.
4. Wenn der Funktionstest eine Parametrisierung hat, sollten wir diese entfernen. Tools für Penetrationstests benötigen nicht mehrere Wertesätze für dieselben Parameter, um zu wissen, was getestet werden soll, und das Senden verschiedener Wertesätze kann nur dazu führen, dass die Testläufe aufgrund doppelter Tests länger werden.
5. API-Funktionstests haben normalerweise Assertionen, die die Antwort des Dienstes validieren. Bei der Verwendung als Sicherheitstests können diese Behauptungen fehlschlagen, werden jedoch bei der Überprüfung der Ergebnisse verrauscht, da wir uns in diesem Zusammenhang nur um die gefundenen Sicherheitslücken kümmern. Wir sollten alle Behauptungen entfernen. In meinem vorherigen Beispiel würde dies bedeuten, den JSON-Assertor aus Test 3 zu entfernen.
6. Einige API-Aufrufe fügen der Datenbank Daten hinzu. Wenn Sie ein Penetrationstest-Tool für solche APIs verwenden, kann die Datenbank aufgrund der Anzahl der Angriffe, die das Penetrationstest-Tool auf die API ausübt, mit Informationen überfüllt sein. In einigen Fällen kann dies zu unerwarteten Nebenwirkungen führen. In einem unserer Entwicklungsteams haben wir ein Leistungsproblem in der Anwendung festgestellt, als eine bestimmte API aufgrund der Penetrationstest-Angriffe viele Daten hinzufügte. Die Anwendungsleistung wurde so schlecht, dass der automatisierte Sicherheitstestlauf nicht in angemessener Zeit abgeschlossen werden konnte. Wir mussten die Sicherheitstests für diese API von unserem automatisierten Lauf ausschließen, bis wir das Problem behoben hatten.

Aufrechterhaltung einer stabilen Testumgebung

Wir müssen überlegen, ob unsere Funktions- und Sicherheitstests in derselben oder einer anderen Testumgebung durchgeführt werden sollen. Das Zurücksetzen der Umgebung zwischen den Funktions- und Sicherheitstestläufen oder die Verwendung einer separaten Umgebung fördert eine bessere Teststabilität, ist jedoch normalerweise nicht erforderlich. Wir können häufig dieselbe Umgebung wiederverwenden, aber wenn wir dies tun, sollten wir zuerst die Funktionstests und zuletzt die Sicherheitstests ausführen, da die Sicherheitstests die Umgebung für die Funktionstests destabilisieren können. Wenn wir verschiedene Umgebungen verwenden, müssen wir sicherstellen, dass wir die ursprünglichen Funktionstestszenarien mit Variablen konfigurieren, damit es einfach ist, die Tests auf verschiedene Endpunkte für verschiedene Umgebungen zu verweisen. SOAtest unterstützt dies mithilfe von Umgebungsvariablen.

Unsere APIs können auch von anderen, außerhalb unserer Kontrolle liegenden APIs abhängen. Wir können die Servicevirtualisierung nutzen , um unsere Umgebung zu isolieren und so Abhängigkeiten von diesen externen Systemen zu vermeiden. Dies trägt zur Stabilisierung unserer Tests bei und verhindert gleichzeitig unbeabsichtigte Auswirkungen unserer Penetrationstests auf externe Systeme.

Fazit

Wir können eine bessere Qualität unserer APIs sicherstellen, indem wir Sicherheitstests als Teil eines automatisierten Prozesses in die Entwicklung und QA verlagern. Wir können unsere bestehenden API-Funktionstests nutzen, um automatisierte Sicherheitstests zu erstellen, die es uns ermöglichen, Sicherheitsfehler früher im Prozess zu entdecken und zu beheben. Und hoffentlich hilft uns dies, nicht zu einer der nächsten großen Schlagzeilen in den Nachrichten zu werden.