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

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.

Darüber hinaus werden Dienste und Anwendungen heute häufiger als je zuvor veröffentlicht, oft bis zu mehrmals am Tag. Diese schnelle Freisetzungskadenz macht den traditionellen Ansatz unhaltbar. In diesem Blog werde ich Schritt für Schritt überprüfen API-Sicherheitscheckliste API-Sicherheitstests zu einem automatisierten Teil des CI-Prozesses zu machen.

Geben Sie Continuous Integration ein

Um dieses Problem zu lösen, wenden wir uns einer Lösung zu, die die Branche verwendet, um Softwarequalitätsprobleme mit beschleunigten Release-Zyklen anzugehen – kontinuierliche Integration. Continuous Integration erstellt Builds, wenn neuer Code eingecheckt wird, und validiert den neuen Code durch Ausführen einer statischen Analyse und Unit-Tests für jeden Build. Wenn Teams erfahren sind, erstellen und führen sie möglicherweise sogar automatisierte Funktionstests mit CI durch (vielleicht nicht für jeden Build, da die Ausführung von Funktionstests normalerweise lange dauert, aber zumindest in bestimmten Intervallen wie einmal am Tag).

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 schreiben und laufen automatisierte Funktionstests für unsere APIs. (Wenn wir dies nicht tun, müssen wir hier beginnen und sind nicht bereit, eine Automatisierung unserer Sicherheitstests in Betracht zu ziehen.) Wenn wir automatisierte Funktionstests für unsere APIs durchführen, können wir dies im Rahmen unserer normalen Entwicklungs- und QA-Prozesse identifizieren eine Teilmenge dieser funktionalen Tests, die als Sicherheitstests verwendet werden. Wir werden diese Teilmenge als Sicherheitstests vorbereiten und ausführen.

Lassen Sie mich beschreiben, wie dies mit funktioniert Parasoft SOAtest und seine eingebaute Unterstützung, die in der 2021.2 Release.

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:

Dieses Szenario werden wir dann mit SOAtest ausführen. Bei der Ausführung jedes Tests führt SOAtest den im Test definierten API-Aufruf durch und erfasst den Anfrage- und Antwortverkehr. Das Penetrationstest-Tool bei jedem Test übergibt die Verkehrsdaten an eine eingebettete Instanz des OWASP ZAP Penetrationstest-Tools, die basierend auf den in den Verkehrsdaten beobachteten API-Parametern Penetrationstests für die API durchführt und dabei ihre eigenen Heuristiken verwendet.

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 APIs abhängen, die sich unserer Kontrolle entziehen. Wir können die Verwendung in Betracht ziehen Dienstvirtualisierung, um unsere Umgebung zu isolieren Wir sind also nicht von diesen externen Systemen abhängig. Dies wird dazu beitragen, unsere Tests zu stabilisieren und gleichzeitig unbeabsichtigte Folgen für die externen Systeme aufgrund unserer Penetrationstest-Bemühungen zu verhindern.

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.

Von Nathan Jakubiak

Nathan ist Entwicklungsdirektor bei Parasoft. Er und seine Teams entwickeln Produktfunktionen in den Bereichen UI-Tests (Selenic), API-Tests (SOAtest), Service-Virtualisierung (Virtualize) und Unit-Tests (Jtest). Er ist seit 2000 bei Parasoft.