Dynamic Application Security Testing (DAST):

DAST-Tools benötigen keinerlei Anwendungswissen, müssen also etwa die verwendete Programmiersprache nicht kennen. So können Sie die Anwendungssicherheit selbst bei eher unbekannten Programmiersprachen verlässlich prüfen.

Worin unterscheidet sich DAST von anderen Prüfverfahren?

Um zu beurteilen, ob sich ein bestimmtes Testverfahren für die jeweilige Umgebung eignet, sollte man dessen Vorteile und Grenzen kennen. Deshalb sollen hier zunächst verschiedene Testverfahren miteinander verglichen werden.

SAST, DAST und SCA

Static Application Security Testing (Statisches Testen der Anwendungssicherheit, SAST) setzt früh in der CI an und scannt Quellcode, Bytecode und Binärcode auf problematische Muster, die nicht den gängigen Best Practices entsprechen. SAST ist programmiersprachenabhängig.

Dynamic Application Security Testing (Dynamisches Testen der Anwendungssicherherheit, DAST) ist ein Blackbox-Prüfverfahren, bei dem Anwendungen in der Laufzeitumgebung geprüft werden. DAST ist in der CI somit weiter hinten angesiedelt. Das Verfahren ist vor allem dazu geeignet, Regressionen zu verhindern, und ist unabhängig von der verwendeten Programmiersprache.

Interactive Application Security Testing (Interaktives Testen der Anwendungssicherherheit, IAST) ist DAST insofern ähnlich, als auch hier Anwendungen in der Laufzeitumgebung geprüft werden. Allerdings kommt dabei eine Kombination aus Blackbox-Tests, Scans und der Analyse anwendungsinterner Abläufe zum Einsatz. Der Vorteil von IAST ist die Möglichkeit, DAST-ähnliche Befunde wie bei SAST mit dem Quellcode in Verbindung zu setzen. Der Nachteil besteht darin, dass IAST programmiersprachenabhängig ist und erst spät in der CI zur Anwendung kommt.

Software Composition Analysis (SCA) erkennt Abhängigkeiten zu Fremdcode, die in der Anwendung zum Einsatz kommen. Das Verfahren ist besonders für Anwendungen geeignet, die mehrere Open-Source-Bibliotheken verwenden. SCA ist ebenfalls programmiersprachenabhängig.

Hier erfahren Sie mehr über SAST und DAST – die Unterschiede und Kombinationsmöglichkeiten.

Wie fügt sich DAST in andere Testverfahren für die Anwendungssicherheit ein?

DAST harmoniert besonders mit Testverfahren für die Anwendungssicherheit, die wie SAST und SCA auf statischen Kontrollen basieren, da sich so die Erkenntnisse aus der Laufzeitumgebung mit einer statischen Quellcodeanalyse verbinden lassen.

Bei SAST werden oft nur einzelne Codebestandteile untersucht, während der größere Zusammenhang außer Acht gelassen wird. So kann es vorkommen, dass Code aus einer Datei als Problem erkannt wird, obwohl Code in einer anderen Datei dieses bereits behebt. Die implementierten Sicherheitssysteme können dabei sogar auf einem völlig anderen Computer ausgeführt werden. Deshalb erkennen SAST-Programme unbereinigte Eingaben als Problem, da sie für deren Bereinigung blind sind, wenn diese auf dem Server unmittelbar vor der Datennutzung erfolgt.

Bei DAST-Tools wird Sicherheit dagegen ganzheitlicher betrachtet. Dabei bleibt allerdings unklar, ob der Client-Code entsprechend Best Practices bei der Eingabe bereinigt wird oder nicht. Betrachtet werden hier ausschließlich Input und Output. Und wenn letzterer bereinigt wird, ist es irrelevant, wo genau dieser Schritt erfolgt.

Zudem können sich Randfälle in der Anwendung für DAST als blinde Flecken erweisen, da hier nur bestimmte Anwendungsfälle abgedeckt werden, nicht aber alle theoretisch möglichen Eingaben. Und genau hier kommen SAST und SCA ins Spiel. Denn diese prüfen den Quellcode auf problematisches Verhalten, das von DAST allein nicht erkannt werden kann.

So können beispielsweise Typumwandlungen fehlschlagen oder zu unerwünschten Resultaten führen. Doch ein DAST-Testszenario, das lediglich zehn Eingaben abdeckt, kann das nicht erkennen. SAST weiß aber, dass Umwandlungen bei bestimmten Werten fehleranfällig sind, die man bei der Implementierung vielleicht gar nicht auf dem Schirm hatte.

DAST: Vor- und Nachteile

Die Tatsache, dass es bei DAST vor allem darum geht, Anwendungen in der Ausführung zu testen, bietet einige Vorteile, bringt aber auch gewisse Nachteile mit sich. Diese sollen hier erläutert werden, damit Sie entscheiden können, ob DAST für Sie die richtige Wahl ist.

Vorteile:

• weniger falsch-positive Ergebnisse: Da nicht die komplette Anwendung gescannt wird, gibt es bei DAST meist weniger falsch-positive Ergebnisse als bei SAST. So lassen sich tatsächliche Schwachstellen viel einfacher erkennen und folglich verhindern.

• Unabhängigkeit von der Programmiersprache: DAST ist das einzige programmiersprachenunabhängige Testverfahren. Bei DAST werden Quellcode, Bytecode und Assemblersprache außer Acht gelassen und ausschließlich Ein- und Ausgaben geprüft. Bei Verwendung eher seltener Programmiersprachen ist DAST daher manchmal die einzige Option.

• schnelle Kontrolle behobener Schwachstellen: DAST kann Regressionen verhindern. Wird eine Sicherheitslücke erkannt und reproduziert, lässt sich dieser Schritt automatisieren und in die DAST-Testsuite einbinden. So enthalten alle nachfolgenden Releases sämtliche Interaktionen, die in der Vergangenheit Probleme gemacht haben. Und treten diese in irgendeiner Form später erneut auf, kann DAST sie rechtzeitig verhindern.

Nachteile:

• keine Codeanalyse: DAST interessiert sich ausschließlich für Inputs und Outputs. So können etwaige Schwachstellen nicht mit den ursächlichen Codezeilen in Verbindung gebracht werden.

• höherer Zeitaufwand: Da die Software ausgeführt und verwendet werden muss, verlangsamen sich selbst automatisierte Testverfahren. Denn die mehrfache Eingabe leicht abgewandelter Werte kostet viel Zeit.

• nachgelagerte Position in CI/CD: DAST befindet sich in CI/CD relativ weit hinten, da es ausführbare Anwendungen erfordert. So verstreicht insbesondere bei größeren Anwendungen viel Zeit.

• manueller Prüfaufwand: Ist eine automatische Ausführung und Nutzung der jeweiligen Anwendung aus irgendeinem Grund nicht möglich, muss DAST komplett aus dem CI/CD-Prozess herausgelöst und die Anwendung vor jedem Release manuell getestet werden.

Tipps zur Implementierung

Da die Anwendungen bei DAST ausgeführt werden müssen, ergeben sich gegenüber SAST einige Nachteile. Zwar lässt sich DAST durchaus automatisieren, doch dazu sind wiederum Skripte oder Aufzeichnungen erforderlich. So ist noch ein weiterer Prozess nötig, der natürlich ebenfalls befolgt werden will.

1\. Rücksprache mit den Benutzern halten

Bevor Sie DAST implementieren, sollten Sie sich mit den Benutzern zusammensetzen und genau herausfinden, wie diese die Anwendung einsetzen. Dabei sollten Sie nicht nur auf die einzelnen Schritte achten, sondern auch nach den Hintergründen fragen.

Denn oft ist den Benutzern gar nicht bewusst, warum sie in einer Anwendung dies oder jenes anklicken. Bei Routineaufgaben vergisst man ja gerne, welchem Zweck sie eigentlich dienen. Und das wiederum kann dazu führen, dass unabsichtlich Probleme verursacht werden.

2\. Benutzerinteraktionen automatisieren

In einem zweiten Schritt zeichnen Sie mit einem Automatisierungstool die Benutzerinteraktionen auf. Das ist bei CLI- und API-Anwendungen viel einfacher als bei GUI, aber grundsätzlich immer machbar.

3\. Testskripte in die CI/CD-Pipeline einbinden

Haben Sie die wichtigsten Anwendungsfälle automatisiert, führen Sie die entsprechenden Skripte aus und lassen sie vom DAST-Tool scannen. Nach dem ersten Durchlauf können Sie bereits erste Sicherheitslücken schließen.

4\. Testsuite um Regressionstests erweitern

Falls Sie bei der gewöhnlichen Anwendungsnutzung Sicherheitslücken feststellen, können Sie die Testsuite um spezifische Skripte ergänzen. So stellen Sie sicher, dass sich die Probleme nicht wiederholen.

Zusammenfassung

DAST ist ein zuverlässiges Verfahren zur Erkennung von Sicherheitslücken, reicht für sich genommen aber nicht aus. In manchen Fällen ist es dennoch das einzige Tool, das einem zur Verfügung steht. Das gilt etwa bei der Verwendung eher seltener Programmiersprachen oder geschlossener Pakete und Erweiterungen für ihre gängigeren Alternativen.

DAST ist zudem vor allem bei komplexen Interaktionen relativ zeitaufwendig. Wenn sich die nicht automatisieren lassen, führt an einer manuellen Prüfung vor jedem neuen Release kein Weg vorbei. Und die kann mehrere Tage oder gar Wochen in Anspruch nehmen.

Auf den ersten Blick erscheint daher SAST gegenüber DAST insbesondere mit Blick auf die frühere Verortung im Entwicklungsprozess als bessere Alternative. Und auch die Behebung festgestellter Sicherheitslücken ist bei SAST einfacher und kostengünstiger. Doch auch DAST bietet etliche überzeugende Vorteile.