Dynamische Anwendungssicherheitstests (DAST)

Ein DAST-Tool benötigt keine Einblicke in Ihre Anwendung, etwa in die Programmiersprache, mit der sie entwickelt wurde. So können Sie die Sicherheit Ihrer Anwendung auch dann verbessern, wenn Sie eine Nischen-Programmiersprache verwenden.

Wie unterscheidet sich DAST von anderen Sicherheitstestmethoden?

Um festzustellen, ob sich eine bestimmte Sicherheitstestmethode für Ihre Anwendungstestumgebung eignet, sollten Sie sowohl ihre Möglichkeiten als auch ihre Einschränkungen berücksichtigen. Sehen wir uns die Unterschiede zwischen den einzelnen Testmethoden an.

SAST vs. DAST vs. SCA

Statische Anwendungssicherheitstests (SAST) konzentrieren sich auf den Code. Sie kommen früh in der CI-Pipeline zum Einsatz und scannen Quellcode, Bytecode oder Binärcode, um problematische Codierungsmuster zu erkennen, die nicht den Best Practices entsprechen. SAST ist von der Programmiersprache abhängig.

Dynamische Anwendungssicherheitstests (DAST) sind eine Black-Box-Testmethode, bei der Anwendungen zur Laufzeit gescannt werden. Sie kommen später in der CI-Pipeline zum Einsatz. DAST eignet sich gut, um Regressionen zu verhindern, und ist nicht von einer bestimmten Programmiersprache abhängig.

Interaktive Anwendungssicherheitstests (IAST) ähneln DAST, da sie sich auf das Verhalten der Anwendung zur Laufzeit konzentrieren. Die IAST-Analyse basiert jedoch eher auf einer Kombination aus Black-Box-Tests, Scans und der Analyse interner Anwendungsabläufe. Ein Vorteil von IAST ist, dass sich DAST-ähnliche Befunde mit dem Quellcode verknüpfen lassen, ähnlich wie bei SAST. Der Nachteil dieses Ansatzes: IAST ist dadurch von der Programmiersprache abhängig und kann erst später in der CI-Pipeline durchgeführt werden.

Software Composition Analysis (SCA) konzentriert sich auf Abhängigkeiten im Anwendungscode von Drittanbietern. Sie ist besonders effektiv bei Anwendungen, die viele Open-Source-Bibliotheken nutzen. Auch diese Methode ist von der Programmiersprache abhängig.

Erfahren Sie mehr über SAST und DAST: Was ist der Unterschied und wie lassen sie sich kombinieren?

Wie ergänzt DAST andere Methoden zum Testen der Anwendungssicherheit?

DAST lässt sich am besten mit Methoden zum Testen der Anwendungssicherheit kombinieren, die auf statischen Prüfungen wie SAST und SCA beruhen, da es die statische Quellcodeanalyse um zusätzliche Einblicke zur Laufzeit ergänzt.

SAST-Tools betrachten oft nur einzelne Codeausschnitte und berücksichtigen deren Kontext nicht. Der Code in einer Datei kann als problematisch eingestuft werden, obwohl Code in einer anderen Datei, der ihn verwendet, alle Probleme behebt. Auch kann die Sicherheit, die Sie in Ihr System eingebaut haben, auf einem ganz anderen Computer ausgeführt werden. Ein SAST-Tool würde beispielsweise eine nicht bereinigte Eingabe als Problem erkennen, weil es sie nicht mit der Bereinigung abgleichen kann, die auf dem Server unmittelbar vor der Verwendung der Daten erfolgt.

DAST-Tools ermöglichen Tests von Anfang bis Ende. Sie wissen nicht, ob der Client-Code Best Practices zur Bereinigung von Eingaben befolgt. DAST-Tools untersuchen die Ein- und Ausgaben Ihrer Anwendung. Wenn die Ausgabe bereinigt ist, spielt es keine Rolle, an welcher Stelle Ihrer Architektur die Bereinigung stattgefunden hat.

Anwendungsbereiche, die nur in Sonderfällen fehlschlagen, können DAST-Tools jedoch entgehen, da sie nur bestimmte Anwendungsfälle und keine theoretischen Eingaben abdecken. Hier kommen SAST- und SCA-Tools ins Spiel. Sie untersuchen den Quellcode und suchen nach problematischem Verhalten, das bei alleiniger Verwendung eines DAST-Tools unentdeckt bliebe.

Bei einer Typumwandlung kann es beispielsweise zu Fehlern oder unerwünschten Ausgaben kommen. Ein DAST-Testfall, der nur 10 Eingaben abdeckt, meldet möglicherweise, dass alles in Ordnung ist. Ein SAST-Tool würde jedoch erkennen, dass eine Umwandlungsmethode bei bestimmten Werten fehleranfällig ist – Werten, die Ihnen bei der Entwicklung Ihrer Anwendung vielleicht gar nicht in den Sinn gekommen wären.

Vor- und Nachteile von DAST

DAST-Tools testen Anwendungen zur Laufzeit. Das bietet zahlreiche Vorteile, bringt aber auch Nachteile mit sich. Wir gehen diese genauer durch, damit Sie beurteilen können, ob DAST zu Ihrem Softwareprojekt passt.

Vorteile:

• Weniger falsch-positive Ergebnisse: Da DAST nicht die gesamte Anwendung scannt, entstehen in der Regel weniger falsch-positive Ergebnisse als bei SAST. So können Sie viel schneller überprüfen, ob eine Sicherheitslücke tatsächlich besteht und ob sie sich später verhindern lässt.

• Sprachunabhängig: DAST ist die einzige Sicherheitstestmethode, die nicht an eine Programmiersprache gebunden ist. DAST untersucht weder Quellcode noch Bytecode oder Assemblercode, sondern prüft lediglich die Ein- und Ausgaben Ihres Systems. Wenn Ihre Anwendung in einer Nischen-Programmiersprache entwickelt wurde, ist DAST möglicherweise Ihre einzige Option.

• Schnelle erneute Prüfung behobener Sicherheitslücken: DAST behält Regressionen im Blick. Wird eine Sicherheitslücke gefunden und reproduziert, lässt sich die Reproduktion automatisieren und in die DAST-Testsuite aufnehmen. So werden bei jeder weiteren Veröffentlichung auch die Interaktionen berücksichtigt, die früher zu Problemen geführt haben. Sollten diese Probleme erneut auftreten, erkennt DAST sie, bevor die Veröffentlichung erfolgt.

Nachteile:

• Keine Einblicke in den Code: DAST untersucht nur die Ein- und Ausgaben Ihres Systems. Daher lassen sich entdeckte Sicherheitslücken nicht mit Codezeilen verknüpfen.

• Langsamerer Testprozess: Die Software muss ausgeführt und verwendet werden, was den Testprozess selbst bei automatisierten Tests verlangsamen kann. Das Durchklicken eines Registrierungsprozesses mit zahlreichen Kombinationen von Eingaben kostet einfach Zeit.

• Ergebnisse erst spät in der CI/CD-Pipeline: DAST ist ganz rechts in Ihrer CI/CD-Pipeline angesiedelt, da DAST-Tools Ihre Anwendung ausführen müssen, um ihre Arbeit zu erledigen. Das kann viel Zeit in Anspruch nehmen, insbesondere wenn Ihre Anwendung im Laufe der Zeit gewachsen ist.

• Manuelle Tests können erforderlich sein: Wenn Sie die Ausführung und Nutzung Ihrer Anwendung aus irgendeinem Grund nicht automatisieren können, müssen Sie die DAST-Prüfung vollständig aus Ihrer CI/CD-Pipeline herausnehmen und die Anwendung vor jeder Veröffentlichung manuell testen.

DAST erfolgreich implementieren

Da DAST auf der Ausführung Ihrer Anwendung beruht, lässt es sich nicht so einfach wie SAST in Ihre Testpipeline integrieren. DAST kann zwar automatisiert werden, doch der zu automatisierende Teil muss zunächst skriptbasiert abgebildet oder aufgezeichnet werden. Nach dem Hinzufügen eines DAST-Tools zu Ihrer Pipeline ist daher ein bestimmter Ablauf erforderlich.

1. Sprechen Sie mit Ihren Nutzern

Ein guter Ausgangspunkt für die Implementierung von DAST ist, sich mit Ihren Nutzern zusammenzusetzen und festzuhalten, wie sie Ihre Anwendung verwenden. Bitten Sie sie nicht nur, ihre Aktionen zu zeigen, sondern auch zu erklären, was sie tun.

Nutzer vergessen oft, worauf sie in einer Anwendung klicken: Häufige Interaktionen laufen unbewusst ab. Das hilft ihnen zwar, sich auf ihre Aufgaben zu konzentrieren, doch nur weil jemand nicht über einen Klick nachdenkt, heißt das nicht, dass er keine Probleme verursachen kann.

2. Nutzerinteraktionen automatisieren

Im nächsten Schritt verwenden Sie ein Automatisierungstool, um die Aktionen der Nutzer zu skripten. Bei CLI- und API-Anwendungen ist das möglicherweise einfacher als bei Anwendungen mit grafischer Benutzeroberfläche. Grundsätzlich ist es jedoch bei allen möglich.

3. Testskripte in Ihre CI/CD-Pipeline integrieren

Wenn Sie die wichtigsten Anwendungsfälle schließlich mit automatisierten Interaktionen abdecken, können Sie die Skripte während eines DAST-Scans Ihrer Anwendung ausführen. Nach dem ersten DAST-Durchlauf können Sie mit der Behebung der Sicherheitslücken beginnen.

4. Regressionstests in die Testsuite aufnehmen

Wenn Sie bei der täglichen Nutzung Ihrer Anwendung Sicherheitslücken entdecken, können Sie spezielle Nutzungsskripte in Ihre Testsuite aufnehmen. So stellen Sie sicher, dass die Probleme künftig nicht erneut auftreten.

Zusammenfassung

DAST ist zwar eine zuverlässige Methode zur Erkennung von Sicherheitslücken, doch allein deckt es nicht alle Bereiche ab. Manchmal ist es jedoch die einzige verfügbare Lösung – etwa wenn Sie Ihre Anwendung mit einer Nischen-Programmiersprache oder mit Closed-Source-Paketen beziehungsweise Erweiterungen für eine gängige Programmiersprache entwickeln.

Die Ausführung eines DAST-Tools kann insbesondere bei komplexen Interaktionen viel Zeit in Anspruch nehmen. Wenn Sie solche Interaktionen nicht automatisieren können, müssen Sie sie vor jeder Veröffentlichung manuell durchführen. Das kann Tage oder sogar Wochen dauern.

Im Vergleich von SAST und DAST scheint SAST insgesamt die bessere Wahl zu sein, da es früher im Entwicklungsprozess eingesetzt werden kann – zu einem Zeitpunkt, an dem sich erkannte Sicherheitsprobleme einfacher und kostengünstiger beheben lassen. DAST-Tools bieten jedoch zweifellos einige große Vorteile.