White-Box-Testing: Sicherheitsrisiken früh im SDLC erkennen

Wenn es um Software-Sicherheit geht, glauben 85 % der Nutzer, dass diejenigen dafür verantwortlich sind, die dem Code am nächsten sind – Entwickler und Engineers. Das überrascht nicht, denn die meisten Schwachstellen entstehen früh im Softwareentwicklungszyklus, noch bevor die Software in der Produktionsumgebung bereitgestellt wird. Ohne Einblick in die getesteten Systeme oder die Software lassen sich viele dieser Schwachstellen nur sehr schwer entdecken.

Hier kommt White-Box-Testing ins Spiel. In diesem Artikel befassen wir uns mit der Methode des Application-Security-Testings, erläutern ihre Durchführung sowie ihre Vor- und Nachteile.

White-Box-Testing erklärt

Diagramm für White-Box-Tests

Das wichtigste Merkmal von White-Box-Testing ist, dass man gewissermaßen „hindurchsehen“ kann. Daher ist es auch als Glass-Box-, Clear-Box-, Transparent-Box- und Open-Box-Testing bekannt. Da der Tester oder das Tool mit der internen Funktionsweise der Software vertraut ist und weiß, was der Code tun soll, lässt sich die Software-Sicherheit prüfen, indem untersucht wird, wie gut die Software Angriffen standhält.

White-Box-Testing ist das Gegenteil von Black-Box-Testing. Beim Black-Box-Testing hat der Security-Tester – wie der Name schon sagt – keinen Zugriff auf die Software oder Netzwerke und weiß daher wenig oder gar nichts über das Zielsystem. Der Penetrationstester prüft die Anwendung auf Schwachstellen, so wie es ein externer Angreifer tun würde.

Zweck von White-Box-Testing

Warum sollte Software einem White-Box-Test unterzogen werden? Warum ist White-Box-Testing wichtig? Dafür gibt es zwei Gründe:

1. Es deckt Sicherheitsrisiken auf.

Laut dem Bericht State of the cloud native application security report waren über 56 % der Nutzer von einem Konfigurationsfehler oder einem Vorfall mit einer bekannten, nicht behobenen Schwachstelle in ihren cloudnativen Anwendungen betroffen. Application Security ist entscheidend, und sie zu vernachlässigen kann katastrophale Folgen haben. Werden Sicherheitslücken rechtzeitig erkannt, lassen sich Risiken beseitigen und hohe Kosten durch Sicherheitsverletzungen vermeiden. Solche Vorfälle können das Vertrauen Ihrer Kunden in Ihren verantwortungsvollen Umgang mit ihren Daten untergraben und sogar zu Klagen führen.

Viele Sicherheitslücken – etwa unsichere Deserialisierung, Fehlkonfigurationen, offengelegte Secrets und fehlerhafte Zugriffskontrollen – sind auf Programmierfehler im Code zurückzuführen. Die von diesen Schwachstellen ausgehenden Risiken lassen sich ohne White-Box-Testing nur schwer beheben.

2. Es deckt Fehler auf und verbessert die Qualität.

Softwareteams arbeiten agil und veröffentlichen häufig Updates, die auf Nutzerfeedback und sich verändernde Märkte reagieren. Regelmäßige Updates und Änderungen sollten bestehende Funktionen nicht beeinträchtigen. Nichts verärgert Nutzer mehr als ein Update, das beliebte Funktionen beeinträchtigt. White-Box-Testing ist entscheidend, um Fehler und inkompatible Änderungen in der Software rechtzeitig zu erkennen.

Kurz gesagt: White-Box-Testing ist unverzichtbar, um Fehler, potenzielle Sicherheitslücken und Performance-Probleme frühzeitig zu erkennen.

Arten von White-Box-Testing

Es gibt verschiedene Arten von White-Box-Testing:

• Ausführungs-/Unit-Testing: Bei dieser Art von White-Box-Testing wird ein Teil des Codes ausgeführt und die Ausgabe mit dem gewünschten Ergebnis verglichen. Wird das erwartete Ergebnis nicht erzielt, liegt ein Fehler vor, der behoben werden muss. Ausführungstests werden kontinuierlich durchgeführt.

• Statisches Testing/Strukturanalyse: Dabei wird eine Codebasis sorgfältig auf Fehler und Schwachstellen untersucht, ohne den Code tatsächlich auszuführen. Ein Tester kann die Codebasis beispielsweise mit statischen Application-Security-Tools (SAST) auf Schwachstellen analysieren. SAST untersucht die Anwendung gründlich anhand bestimmter Kriterien wie Konfigurationsanalyse, semantischer Analyse und Datenflussanalyse, um den Quellcode zu schützen.

• Mutation-Testing: Dies findet üblicherweise als letzter Schritt statt. Dabei werden allgemeine Fehlerprüfungen durchgeführt und die optimalen Programmierstrategien für die Erweiterung des Programms ermittelt.

Was wird getestet?

Zunächst müssen Sie für White-Box-Testing die zu testende Software verstehen und den Code sowie sein erwartetes Verhalten kennen. Als Nächstes erstellen Sie Testfälle, indem Sie zusätzlichen Code schreiben. Damit überprüfen Sie, wo bei der Ausführung Fehler auftreten und Schwachstellen ausgenutzt werden könnten.

Im Allgemeinen umfasst White-Box-Testing Folgendes:

• Interne Sicherheitslücken

• Den Fluss bestimmter Eingaben durch den Code

• Erwartete und unerwartete Ausgaben

• Fehlerhafte oder schlecht strukturierte Codepfade

• Die Logik bedingter Schleifen

• Das Verhalten der einzelnen Funktionen und Klassen

• Den Umgang der Software mit bestimmten Eingaben

White-Box-Testing-Techniken

White-Box-Penetrationstests sind ein wichtiger Bestandteil von Sicherheitstests, da sie eine umfassende Analyse interner und externer Schwachstellen ermöglichen. Die Zusammenarbeit von Security-Testern und Entwicklern schafft ein tiefes Verständnis des Systems und der möglichen Wege, es auszunutzen. Eine White-Box-Testing-Technik könnte beispielsweise darin bestehen, die Sicherheit und Zuverlässigkeit einer Banking-App zu prüfen und sicherzustellen, dass ihre Geschäftslogik keine Schlupflöcher aufweist.

Zu den gängigen Techniken beim White-Box-Testing gehören:

• Bedingungsüberdeckung: Eine Technik, mit der Variablen in Teilausdrücken anhand logischer Bedingungen getestet werden.

• Anweisungsüberdeckung: Bei dieser Technik wird eine Reihe von Tests für Anweisungen im Code ausgeführt. Sie wird häufig auch Zeilenüberdeckung genannt. Jede Anweisung wird mindestens einmal getestet.

• Zweigüberdeckung: Mit dieser Technik stellen Tester sicher, dass jeder Codezweig mindestens einmal getestet wird.

• Pfadüberdeckung: Wird in der Regel durchgeführt, um jeden einzelnen Pfad in einer Anwendung zu testen.

• Datenflusstest: Dient dazu, den Datenfluss in einer Software im Hinblick auf die Variablen im Code zu untersuchen.

White-Box- und Black-Box-Testing im Vergleich

White-Box- und Black-Box-Testing sind Methoden, um Fehler in Software aufzudecken. Beide sind verbreitete Testverfahren, unterscheiden sich jedoch deutlich. Die folgende Tabelle zeigt die wichtigsten Unterschiede.

Diagramm zum Black-Box-Testing

White-Box- und Black-Box-Tests sind daher nicht austauschbar. Es reicht nicht aus, nur eines der beiden Verfahren einzusetzen. Vielmehr ergänzen sie sich und tragen gemeinsam dazu bei, bessere Software bereitzustellen. Werden White-Box- und Black-Box-Techniken kombiniert, spricht man von Gray-Box-Testing.

Vor- und Nachteile von White-Box-Testing

White-Box-Testing hat eigene Vor- und Nachteile.

Vorteile:

• Der Tester kennt das zu testende System bereits. Dadurch lässt sich viel Zeit sparen, die sonst für die Informationsbeschaffung oder die Erkundung des Systems nötig wäre.

• Gründlichere Tests und die Entdeckung von mehr Sicherheitsrisiken als bei jeder anderen Testtechnik.

• Dank des Low-Level-Ansatzes lässt sich die Technik mit automatisierten Sicherheitstools wie SonarQube in CI-Pipelines integrieren.

• Die Technik ist näher am Code, sodass Entwickler entdeckte Schwachstellen einfach beheben können.

Nachteile:

• Aufgrund seiner Gründlichkeit ist dies die zeitaufwendigste und teuerste Testtechnik.

• Erfordert umfassende Kenntnisse des zu testenden Systems.

Fazit

Aufgrund seiner Eigenschaften ist White-Box-Testing ein wichtiger Bestandteil der DevOps-Kultur im Secure Software Development Life Cycle. Da sich White-Box-Tests automatisieren lassen, werden sie üblicherweise in CI-Pipelines ausgeführt. So erhalten Entwickler schnelles Feedback, während sie ihren Code überprüfen.

White-Box-Sicherheitstesttools wie Snyk Code integrieren statisches Application-Security-Testing in die DevSecOps-Pipeline. So erhalten Entwickler die erforderliche umfassende Testabdeckung, um Sicherheitsrisiken früh genug im Entwicklungsprozess zu erkennen.