Wie Sie Ihre Webanwendung mit Hilfe von Interactive Application Security Testing (IAST) sicherer machen - Teil 3 der Serie Application Security Testing

Einführung

Willkommen zum dritten Teil der Blogserie über Application Security Testing. Im ersten Teil dieser Serie haben wir uns mit der statischen Anwendungssicherheitsprüfung (SAST) und im zweiten Teil mit der dynamischen Anwendungssicherheitsprüfung (DAST) beschäftigt. Falls Sie diese verpasst haben, können Sie sie hier nachlesen: Anwendungssicherheitstests Teil 1 (SAST) und Anwendungssicherheitstests Teil 2 (DAST). In diesem Blog werden wir uns mit Interactive Application Security Testing (IAST) beschäftigen. Zunächst gibt es eine kurze Erklärung zu IAST. Dann gibt es eine kurze Zusammenfassung der Vor- und Nachteile von IAST. Zum Schluss werden wir uns einen Spaß daraus machen, die IAST-Lösung von Contrast Security an einer angreifbaren Java-Anwendung auszuprobieren.

Abbildung 1: IAST und andere Arten von Anwendungstests während der Entwicklungsphasen

IAST funktioniert besonders gut, wenn es zusammen mit Integrations- oder End-to-End-Tests verwendet wird, die während der Testphase der Pipeline gelesen werden. Es ist sogar möglich, den Build zu unterbrechen, wenn Sicherheitslücken gefunden werden, oder Ergebnisse aus verschiedenen Umgebungen zu vergleichen.

Eine andere Möglichkeit ist die Verwendung von IAST während der lokalen Entwicklung. Ein Entwickler erhält Echtzeit-Feedback, wenn er oder sie die Anwendung lokal testet. Das bedeutet, dass Sicherheitsschwachstellen behoben werden können, noch bevor ein Pull Request initialisiert wird. Einige Anbieter bieten ein IDE-Plugin an, das einen leichtgewichtigen Agenten einbettet, der die Ergebnisse direkt in die IDE des Entwicklers bringt. Zusätzlich zum IDE-Plugin bieten einige Anbieter auch eine Integration über Build-Tools wie Gradle oder Maven an. Dadurch wird sichergestellt, dass das IAST-Tool immer dort läuft, wo die Anwendung bereitgestellt wird. Außerdem bedeutet dies weniger Konfigurationsaufwand für die einzelnen Entwickler, da die Integration nur einmal hinzugefügt werden muss.

Wie funktioniert IAST?

Lassen Sie uns die Funktionsweise von Interactive Application Security Testing aus einer übergeordneten Perspektive betrachten. Ein IAST-Tool ist ein Produkt, das eine Anwendung mit Hilfe von Instrumenten auf Sicherheitsschwachstellen untersucht. In diesem Fall bedeutet Instrumentierung das Hinzufügen von Code zu einer Anwendung zur Laufzeit mit dem Ziel, das Verhalten der Anwendung anhand einer Reihe von Sicherheitsregeln zu überwachen. Dies geschieht über einen Agenten. Der Agent muss zusammen mit Ihrer Anwendung geladen werden. Sobald er geladen ist, werden die Interaktionen in der Anwendung kontinuierlich analysiert. Er gibt in Echtzeit Rückmeldung über Schwachstellen und stellt sie im IAST-Sicherheits-Dashboard zur Verfügung. Es spielt keine Rolle, wie diese Interaktionen ausgelöst werden. Es kann ein Mensch sein, der die Anwendung manuell testet, oder ein automatisierter Prozess, der funktionale Tests gegen die Anwendung durchführt. Es ist nicht notwendig, bei der Durchführung der Tests bösartige Nutzdaten zu verwenden. Wenn Sie mehr über die Instrumentierung in Java erfahren möchten, lesen Sie bitte nach: Java-Instrumentierung.

 

Abbildung 2: Übersicht über IAST auf hoher Ebene

 

AVor- und Nachteile von IAST

Vorteile

• Erkennt Sicherheitsprobleme zur Laufzeit in Echtzeit durch Analyse des Anwendungsverhaltens zur Laufzeit
• Schnell - Analyse und Ergebnisse werden in Echtzeit bereitgestellt, während die Anwendung getestet wird
• Umfassende Ergebnisse vom URL/Parameter-Eingabepunkt bis zur Quellcodezeile und vollständige Datenflussanalyse
• Signifikant geringere Rate an Fehlalarmen (Beispiel: Contrast Security erreicht beim unabhängigen OWASP-Benchmark eine Genauigkeit von 100%, verglichen mit dem besten SAST-Tool, das 55% erreicht)
• Die Einsicht in die Testabdeckung hebt Endpunkte und Routen hervor, die zusätzliche Tests erfordern.
• Einfach zu skalieren, da keine besonderen Fachkenntnisse erforderlich sind
• Native Unterstützung für die Integration mit Drittanbietern wie SIEM-Tools, Tracking-Tools, Chat-Tools und mehr sowie eine ansprechende API
• Kann zu einem frühen Zeitpunkt im Softwareentwicklungszyklus verwendet werden, aber Sie müssen in der Lage sein, eine laufende Anwendung mit dem IAST-Agenten irgendwo einzusetzen (lokal oder auf einem Testserver).
• Bringt Sicherheit und QA in Einklang, da das IAST-Tool Einblicke in die Testabdeckung der Anwendung bietet.

Benachteiligungen

• Wie statische Anwendungstests (SAST) ist auch IAST programmiersprachenspezifisch. Nicht jeder Anbieter unterstützt möglicherweise Ihren Stack
• Die Abdeckung hängt von der Vollständigkeit der manuellen oder automatisierten Funktionstests ab (treffen sie alle relevanten Endpunkte der Webanwendung mit Interaktionen)
• Kommerzielle Tools mit proprietärer Software bedeuten Abhängigkeit vom Anbieter für neue Sicherheitsregeln
• Der Agent stellt ein kleines Risiko dar, vergleichbar mit dem Hinzufügen einer Bibliothek. Ähnlich wie bei Tools zur Überwachung der Anwendungsleistung und Beobachtbarkeit.
• Client-seitiger Code wird nicht auf Schwachstellen überprüft. Dennoch prüft IAST, ob nicht vertrauenswürdige Eingaben in den client-seitigen Code gelangen.
• Wie bei statischen Anwendungstests: Änderungen an HTTP-Anfragen durch zwischengeschaltete Kontrollen werden nicht erkannt. Zum Beispiel: das Entfernen oder Hinzufügen von Headern durch einen Reverse Proxy. Dies gilt auch für dynamische Anwendungstests, wenn die Tests direkt auf der Anwendung stattfinden (z.B. in einer Testumgebung, in der keine Reverse Proxies vorhanden sind).

Wenn Sie sich die oben genannten Punkte ansehen, scheint es einige Nachteile zu geben. Sie sind aufgelistet, um Sie darauf aufmerksam zu machen, dass Sie das Tool und den Prozess drum herum feinabstimmen sollten. Sie können überwunden werden, indem Sie Maßnahmen ergreifen, um ihnen zu begegnen. Indem Sie zum Beispiel recherchieren, welche IAST-Tools Ihren Stack unterstützen, wird der erste Nachteil gemildert.

Demo mit Contrast Assess Community Edition

In diesem Teil werden wir die verwundbare Java-Webanwendung mit einem IAST-Tool von Contrast Security namens Contrast Assess testen. Dieses Tool ist Teil der Contrast Security Suite, die auch die folgenden Tools zum Testen der Anwendungssicherheit bietet: Static Application Security Testing (SAST), Software Composition Analysis (SCA), Runtime Application Self Protection (RASP) und einen Serverless Security Scanner. Wir werden uns die SCA-Lösung in einem späteren Blog ansehen. Wenn Sie sich auch für die SAST-Lösung interessieren, können Sie sie hier kostenlos ausprobieren: Contrast Scan. Ich habe mich für Contrast Assess entschieden, weil es eine kostenlose Community-Edition gibt und ich die Plattform mag. Ich habe auch ein Video-Tutorial für den ersten Teil der Demo erstellt, das Sie hier finden: tutorial.

Es ist an der Zeit, praktisch zu werden. Wie ich bereits erwähnt habe, werden wir eine verwundbare Java-Webanwendung scannen. Sie können den Quellcode hier herunterladen: verwundbare Webanwendung

1. Laden Sie zunächst die verwundbare Webanwendung in einen Ordner Ihrer Wahl herunter.
2. Starten Sie ein Terminal und navigieren Sie zum Stammverzeichnis der verwundbaren Webanwendung.
3. Laden Sie die neueste Version des Contrast Security Java Agent herunter, indem Sie diesen Befehl im Terminal verwenden curl -Lhttps://repo1.maven.org/maven2/com/contrastsecurity/contrast-agent/5.1.0/contrast-agent-5.1.0.jar-o contrast-agent.jar und das Terminal geöffnet lassen. Wenn der Befehl curl nicht funktioniert, prüfen Sie die neueste Version in maven und ersetzen Sie die Versionsnummer (fett gedruckt) in der URL.

Der nächste Schritt ist die Registrierung eines Kontos bei Contrast Security für den Zugang zur Community-Edition.

1. Öffnen Sie einen Browser und geben Sie die folgende URL ein: Contrast Community Edition. Unten auf der Seite können Sie ein Konto erstellen.
2. Sobald Sie Ihre Daten eingegeben haben, erhalten Sie eine E-Mail mit einem Link, über den Sie Ihr Passwort festlegen können. Legen Sie Ihr Passwort fest und stimmen Sie den Bedingungen zu.
3. Melden Sie sich unter https:// ce.contrastsecurity.com/Contrast/static/ng/index.html#/pages/signin mit Ihrer E-Mail-Adresse und Ihrem Passwort an.
4. Klicken Sie auf "Erste Schritte", akzeptieren Sie die Bedingungen und klicken Sie auf die Schaltfläche "Weiter". Klicken Sie nun auf die Schaltfläche "Start Agent Setup".
5. Sie müssen keinen Agenten auswählen, da wir ihn bereits heruntergeladen haben. Das einzige, was Sie brauchen, ist die Konfigurationsdatei. Klicken Sie auf "Download the Java contrast_security.yaml" und speichern Sie die Datei im Stammverzeichnis der anfälligen Webanwendung.
6. Klicken Sie auf die Schaltfläche "Schließen".

Kehren Sie zu dem geöffneten Terminalfenster zurück, das den Stammordner der verwundbaren Webanwendung anzeigen sollte. Es ist an der Zeit, die Anwendung zusammen mit dem Agenten zu starten. Stellen Sie sicher, dass Sie Java 17 oder niedriger installiert haben. Sie können Java hier herunterladen: Java. Führen Sie den folgenden Befehl im Terminal aus: java -javaagent:./contrast.jar -Dcontrast.config.path=contrast_security.yaml -jar vulnapp-0.0.1-SNAPSHOT.jar

Öffnen Sie den Browser und navigieren Sie zu http://localhost:8080 und beginnen Sie mit der Navigation durch die verschiedenen Seiten der Webanwendung. Registrieren Sie einen Benutzer, melden Sie sich bei der Anwendung an, schreiben Sie eine Nachricht, sehen Sie sich eine Nachricht an, melden Sie sich ab usw... Der Contrast Agent analysiert die Webanwendung im Hintergrund und sendet alle gefundenen Sicherheitslücken an das Contrast Security Dashboard.

Ergebnisse von Contrast Assess

Melden wir uns unter ce.contrastsecurity.com/Contrast/static/ng/index.html#/pages/signin an. Sobald Sie eingeloggt sind, klicken Sie auf "Anwendungen" und den Namen der verwundbaren Anwendung, die wir gerade getestet haben. In der Übersicht der Anwendung sehen wir, dass sie von Contrast mit einem Risikowert von D bewertet wurde. Das ist ziemlich schlecht, denn A ist die höchste Bewertung und F die niedrigste. Die Bewertung basiert auf Schwachstellen, die im benutzerdefinierten Code und den Bibliotheken der Anwendung gefunden wurden. Wir werden uns zunächst auf den benutzerdefinierten Code konzentrieren. Die Ergebnisse der Bibliotheken werden im nächsten Blog besprochen. Klicken Sie auf "Schwachstellen".

Sie sehen eine Übersicht über alle Schwachstellen, die Contrast Assess gefunden hat. Meine Ergebnisse sind in Abbildung 3 dargestellt. Eine kleine Randnotiz: In der Community-Ausgabe von Contrast Assess sind nicht alle Regeln aktiviert. Von den 49 verfügbaren Regeln sind 37 aktiv. Mit anderen Worten: 12 Regeln sind nicht aktiviert. Sie finden die Regeln auf der Registerkarte "Richtlinien" in der Übersicht der gefährdeten Webanwendungen.

Abbildung 3: Contrast Assess Ergebnisse für gefährdete Webanwendungen

Contrast Assess hat 7 Schwachstellen gefunden. Aus Zeitgründen werden wir uns auf die kritischen Ergebnisse konzentrieren. Es wurden zwei kritische Sicherheitslücken gefunden. Beide sind "SQL Injections". Die "SQL Injection" auf der Seite /login wurde auch von ZAP gefunden. Die "SQL Injection" in der Seite /posts wurde von Semgrep gefunden.

Da wir bereits im ersten Blog über SAST die "SQL Injection" auf der Seite /posts besprochen haben. Wir werden nun die "SQL Injection" auf der /login-Seite besprechen, die im zweiten Blog über DAST kurz erwähnt wurde.

Wenn wir auf der Seite mit den Sicherheitslücken der verwundbaren Webanwendung auf den Eintrag "SQL Injection from "email" Parameter, "password" Parameter on "/login" page" klicken, wird eine Übersichtsseite der Sicherheitslücke angezeigt. Die gleiche Übersicht, die auch in Abbildung 4 angezeigt wird.

Abbildung 4: Übersicht über die /login "SQL Injection"-Schwachstelle

Die Übersicht zeigt, dass die Parameter password und email über Zeile 24 in der Klasse UserRepositoryImpl in einer Datenbankabfrage gelandet sind. Es wird auch erklärt, was das Risiko einer "SQL Injection" bedeutet. Wenn Sie weitere Details wünschen, klicken Sie auf die Registerkarte "Details". Die Registerkarte "HTTP Info" zeigt die HTTP-Anfrage, die die Sicherheitslücke auslöst. Die Registerkarte "Abhilfe" gibt uns Informationen darüber, wie wir "SQL Injection" verhindern können. Der Ratschlag lautet, 'CallableStatement' für gespeicherte Prozeduren und 'PreparedStatement' für normale Abfragen zu verwenden. In unserem Fall sollten wir ein 'PreparedStatement' verwenden, da wir keine gespeicherte Prozedur verwenden.

Lassen Sie uns einen Blick auf den Code werfen:

Abbildung 5: Anfälliger Code - "SQL Injection" /login

In Zeile 24 wird ein String namens "myCustomComplicatedQuery" an ein Query-Objekt namens "nativeQuery" übergeben, das dann zum Abrufen von Ergebnissen aus der Datenbank verwendet wird. In diesem Fall verwenden wir die Java Persistence API auf unsichere Weise, da wir nicht validierte Benutzereingaben in den 'String' namens "myCustomComplicatedQuery" verketten und diesen String direkt verwenden, um eine "Native Query" mit dem 'EntityManager' zu erstellen. Diese "Native Abfrage" wird von 'EntityManager' verwendet, um Ergebnisse aus der Datenbank zu holen.

Um dies zu beheben, sollten wir den Code so ändern, dass ein 'PreparedStatement' verwendet wird. Anstatt eine SQL-Abfrage zu senden, in die Benutzereingaben eingebettet sind, was es der Datenbank unmöglich macht, zwischen der SQL-Abfrage und den Benutzereingaben zu unterscheiden. Es wird eine SQL-Abfrage mit Platzhaltern in Form von Fragezeichen verwendet. Die SQL-Abfrage mit Platzhaltern wird von der Datenbank vorkompiliert. Dies ermöglicht es der Datenbank, zwischen der Abfrage und den Benutzerparametern zu unterscheiden. Später, beim Abrufen der Daten aus der Datenbank, werden die Platzhalter durch die Benutzereingaben ersetzt. Dies verhindert eine "SQL Injection" oder mit anderen Worten eine Manipulation von SQL-Abfragen.

Wir können ein 'PreparedStatement' für die Java Persistence API wie folgt implementieren:

Abbildung 6: Behobener Code - "SQL Injection" /login

Wenn Sie testen möchten, ob die Sicherheitslücke behoben ist. Gehen Sie zurück zum Contrast Security Dashboard und löschen Sie den SQL-Injection-Fund. Starten Sie die Anwendung mit dem Agenten neu und melden Sie sich erneut an. Diesmal wird die SQL-Injection nicht gefunden. Das bedeutet, dass die obige Korrektur wie vorgesehen funktioniert hat. Die Enterprise Edition von Contrast verfügt über diese Funktion und markiert die Sicherheitslücke automatisch als behoben, wenn der Agent bei nachfolgenden Builds/Testläufen feststellt, dass die Sicherheitslücke behoben wurde.

Neben Contrast Assess erhalten wir auch eine Vorschau darauf, was Contrast Protect (die Runtime Application Self Protection (RASP) Lösung) leisten kann. Contrast Protect kann Angriffe blockieren. Dieses Verhalten kann durch Einschalten des Schutzes auf der Registerkarte "Richtlinie" aktiviert werden. In der Community Edition kann es für mehrere Umgebungen aktiviert werden: "Entwicklung", "QA" und "Produktion". Vergewissern Sie sich, dass der Modus "Schützen" für die Regel "Cross Site Scripting" für die Umgebung "Entwicklung" aktiviert ist. Sie sollte den Status "Blockieren" haben.

Nebenbei bemerkt: Der Contrast-Agent kann so konfiguriert werden, dass er im Modus "Bewerten" oder "Schützen" läuft. Technisch gesehen verhält sich der Agent je nach dem Modus, in dem er läuft, unterschiedlich. Im Modus "Schutz" muss er leistungsfähiger sein, da er normalerweise in einer Produktionsumgebung läuft. Deshalb ist es erforderlich, die Anwendung mit dem Agenten neu zu starten, wenn Sie zwischen den Modi "Bewerten" und "Schützen" wechseln.

Abbildung 7: Einige der Schutzregeln von Contrast Security

Der Cross-Site-Scripting-Angriff, den OWASP ZAP gefunden hat, wurde zwar nicht gefunden, aber der Angriff wird blockiert, da der Schutz standardmäßig aktiviert ist. Versuchen Sie, die Nutzlast <script>alert('xss')</script> in das Formular unter http://localhost:8080/posts?postId=1 einzugeben. Sie werden eine Fehlerseite erhalten. Wenn Sie sich die Protokollierung der Webanwendung in dem Terminal ansehen, in dem Sie die Anwendung gestartet haben, werden Sie eine AttackBlockedException sehen. Diese Exception wird durch den Contrast Security Agent ausgelöst. Mit anderen Worten, der Contrast Security Agent bietet im "Schutzmodus" eine Eingabevalidierung gegen Cross Site Scripting-Angriffe. Auch wenn Sie sich der XSS-Schwachstelle nicht bewusst sind, werden Sie zumindest wissen, dass die Eingabeüberprüfung fehlt.

Die Tatsache, dass Contrast Assess diese "Persistent Cross Site Scripting"-Schwachstelle (auch bekannt als "Stored Cross Site Scripting") übersehen hat, ist eine Folge der internen Funktionsweise des Agenten und seiner Feinabstimmung, um Fehlalarme zu vermeiden. Es ist jedoch möglich, zusätzliche Arten von Sicherheitslücken zu unterstützen, indem ein Canary-Wert verwendet wird. Contrast beschreibt dies als "Ein Wert, der von Angriffstesttools gefüttert wird, um gespeicherte XSS- oder andere Injektionsangriffe zweiter Ordnung zu testen, die aus Datenbanken kommen". Wir können einen Canary-Wert hinzufügen, indem wir den Befehl, der den Agenten und die Anwendung startet, wie folgt ergänzen: -Dcontrast.assess.second_order_canary=<payload>

Normalerweise benötigt Contrast Assess keine bösartigen Payloads, um Sicherheitslücken zu finden. Wenn wir Canaries verwenden, müssen Sie den Wert (<payload> Teil des obigen Befehls) verwenden, den Sie mit '-Dcontrast.assess.second_order_canary' eingegeben haben, um die Sicherheitslücke zu finden. Von außen sieht es eher wie ein herkömmlicher DAST-Scanner aus, aber das ist nicht der Fall. Ich untersuche immer noch den internen Datenfluss der Anwendung anstelle von HTTP-Anfragen und Antworten.

Lassen Sie uns die "Persistent Cross Site Scripting"-Schwachstelle aufspüren. Starten Sie die Anwendung und den Agenten über das Terminal mit dem folgenden Befehl:

java -javaagent:../contrast/contrast.jar -Dcontrast.config.path=../contrast/contrast_security.yaml -Dcontrast.assess.second_order_canary="<script>alert('xss')</script>" -jar vulnapp-0.0.1-SNAPSHOT.jar

Zunächst müssen wir die Schutzfunktion für die anfällige Webanwendung deaktivieren. Rufen Sie die Richtlinienseite der anfälligen Webanwendung auf, indem Sie im Dashboard von Contrast Security auf die anfällige Anwendung klicken. Klicken Sie auf die Registerkarte "Richtlinie" und dann auf die Registerkarte "SCHÜTZEN". Verwenden Sie die Dropdown-Schaltfläche der Regel Cross Site Scripting und setzen Sie sie für alle drei Umgebungen auf "AUS". Jetzt ist der Schutz für Cross Site Scripting deaktiviert.

Wir werden einen neuen Benutzer registrieren, um zu demonstrieren, dass Contrast Assess nur einen Fund für Skript-Tags erstellt, die nicht ausgabecodiert sind. Wechseln Sie zu http://localhost:8080/register. Registrieren Sie eine beliebige "E-Mail-Adresse" oder ein beliebiges "Passwort", aber verwenden Sie die Nutzlast <script>alert('xss')</script> als vollständigen Namen. Melden Sie sich nun als der soeben erstellte Benutzer an. Beachten Sie, dass die Seite den Text "Willkommen auf Ihrer Homepage, <script>alert('xss')</script>!" anzeigt. Hier gibt es kein Problem, da das <script>alert('xss')</script> ausgabeverschlüsselt ist. Navigieren Sie nun zum Dashboard von Contrast Security unter ce.contrastsecurity.com/Contrast/static/ng/index.html#/pages/signin und sehen Sie sich die Schwachstellen der anfälligen Webanwendungen an. Es gibt keine neuen Erkenntnisse. Obwohl wir also die Nutzlast <script>alert('xss')</script> verwendet haben, die mit dem Canary-Wert identisch ist, versteht Contrast Assess, dass dies in diesem Fall kein Problem darstellt.

Navigieren Sie nun über den Browser zu http://localhost:8080/posts?postId=1. Erstellen Sie über das Formular einen neuen Beitrag mit dem Text <script>alert(1)</script>. Gehen Sie zurück zum Contrast Security Dashboard und stellen Sie fest, dass es keine neuen Erkenntnisse gibt. Contrast Assess erkennt es nicht, weil die Nutzlast sich von der unterscheidet, die wir als Canary-Wert verwendet haben.

Lassen Sie es uns noch einmal versuchen. Erstellen Sie einen neuen Beitrag mit dem Text <script>alert('xss')</script> und kehren Sie zum Contrast Security Dashboard unter ce.contrastsecurity.com/Contrast/static/ng/index.html#/pages/signin zurück. Jetzt hat Contrast Assess die "Persistent Cross Site Scripting"-Schwachstelle gefunden, wie in Abbildung 7 dargestellt:

Abbildung 8: Die Ergebnisse des Contrast Security Dashboard beinhalten Stored Cross Site Scripting

Beachten Sie, dass Contrast Assess im Gegensatz zu OWASP ZAP (dem DAST-Tool, das wir im zweiten Blog dieser Serie verwendet haben) nicht das falsch positive "Reflected Cross Site Scripting" meldet. Wenn Sie sich die Details der "Persistent Cross Site Scripting"-Schwachstelle ansehen, finden Sie nicht den genauen Ort des Problems: die Codezeile in der posts.html-Vorlage, die für die Schwachstelle verantwortlich ist (erklärt in Teil 2 dieser Blogserie). Aber es liefert Ihnen mehr relevante Informationen als OWASP ZAP. OWASP ZAP gibt nur den Standort des verwundbaren Endpunkts an. Contrast Assess zeigt Ihnen auch an, dass eine Schreibfunktion ohne vorherige Validierung und Verschlüsselung durch eine Klasse von Thymeleaf aufgerufen wurde, wie in Abbildung 9 zu sehen ist.

Abbildung 9: Details zur "Persistent Cross Site Scripting"-Schwachstelle und Aufruf durch Thymeleaf

Denken Sie daran: Wenn Sie Canary-Werte verwenden, stellen Sie sicher, dass Ihre manuellen oder automatisierten Tests die gleichen Werte enthalten.

Bitte beachten Sie, dass wir die Community-Edition verwendet haben und die Vollversion über mehr Funktionen und Sicherheitsregeln verfügt. In diesem Blog möchte ich Ihnen Interactive Application Security Testing vorstellen. Ich plane, in naher Zukunft einen Blog über die Contrast Security Plattform zu schreiben. Bleiben Sie also auch dafür auf dem Laufenden.

Damit ist der Blog über Interaktive Anwendungstests abgeschlossen. In der nächsten Ausgabe werden wir uns mit der Software-Kompositionsanalyse und dem geheimen Scannen beschäftigen. Wir sehen uns beim nächsten Mal!