Sehen Sie, welche API-Testlösung im GigaOm Radar Report am besten abgeschnitten hat. Holen Sie sich Ihren kostenlosen Analystenbericht >>

Sehen Sie, welche API-Testlösung im GigaOm Radar Report am besten abgeschnitten hat. Holen Sie sich Ihren kostenlosen Analystenbericht >>
Zum Abschnitt springen
Wie automatisieren Sie API-Tests, um sie skalierbar und nachhaltig zu machen? Lesen Sie weiter, um die Antwort auf diese und weitere Fragen zu erhalten.
Zum Abschnitt springen
Zum Abschnitt springen
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.
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.
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:
Wir werden dieses Szenario dann mit SOAtest ausführen. Bei jedem Test führt SOAtest den im Test definierten API-Aufruf aus und erfasst den Anfrage- und Antwortverkehr. Das Penetrationstest-Tool übergibt bei jedem Test die Verkehrsdaten an eine eingebettete Instanz des OWASP ZAP-Penetrationstest-Tools, das Folgendes ausführt: auf der API basierend auf den API-Parametern, die es in den Verkehrsdaten beobachtet, und mithilfe seiner eigenen Heuristik.
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:
Bei der Wiederverwendung von Funktionstests zur Verwendung als Penetrationstests sind einige Dinge zu beachten:
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.
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.