White-Box-Test einfach erklärt
Bei einem Penetrationstest greifen Fachleute Systeme mit Erlaubnis an, um Schwachstellen zu finden. Wie viel sie vorab wissen, bestimmt die Testart. Beim Black-Box-Test wissen sie fast nichts – wie ein Angreifer von außen. Beim Grey-Box-Test erhalten sie ausgewählte Informationen. Beim White-Box-Test liegt alles offen: Die „Kiste“ ist gewissermaßen durchsichtig.
Ein Vergleich: Ein Gutachter, der ein Haus nur von außen betrachtet, sieht Risse in der Fassade. Ein Gutachter mit Bauplänen, Schlüsseln und Zugang zum Keller findet auch die feuchte Wand hinter dem Schrank und die marode Leitung unter dem Putz. Genau diesen Unterschied macht der White-Box-Ansatz.
So funktioniert ein White-Box-Test
Was das Prüfteam erhält, hängt vom Prüfgegenstand ab. Typisch sind:
- Dokumentation: Architekturdiagramme, Netzpläne, Datenflüsse und Schnittstellenbeschreibungen.
- Zugänge: Testkonten für alle Rollen – vom einfachen Nutzer bis zum Administrator.
- Quellcode: bei Anwendungen der Programmcode, oft kombiniert mit einem manuellen Code Review, also einer Durchsicht durch Fachleute.
- Konfigurationen: etwa von Servern, Cloud-Diensten, Firewalls oder der zentralen Benutzerverwaltung wie Active Directory.
- Ansprechpersonen: Fachleute aus Entwicklung oder Betrieb, die Rückfragen schnell beantworten.
Mit diesem Wissen prüft das Team gezielt die heiklen Stellen: Wo werden Berechtigungen geprüft? Wie werden Passwörter gespeichert? Welche Funktionen sind versteckt, aber erreichbar? Automatisierte Codeanalysen (SAST) helfen, Auffälligkeiten schnell zu finden. Ob sich ein Fund tatsächlich ausnutzen lässt, belegt anschließend der praktische Test am laufenden System.
Ein Beispiel aus der Praxis
Ein Softwareanbieter entwickelt ein Online-Portal, über das Stadtwerke ihren Kunden Verbrauchsdaten bereitstellen. Vor dem Livegang beauftragt er einen White-Box-Test. Das Prüfteam erhält den Quellcode, ein Architekturdiagramm und Testkonten für alle Rollen.
Im Code stößt es auf eine Exportfunktion, die ein Entwickler zum Testen angelegt und nie entfernt hat. Sie ist nirgends verlinkt und prüft nicht, wer sie aufruft – wer die Adresse kennt, kann Verbrauchsdaten aller Kunden herunterladen. Von außen wäre sie kaum aufgefallen. Außerdem findet das Team einen fest im Code hinterlegten Zugangsschlüssel für einen Cloud-Speicher.
Beide Probleme werden vor dem Start behoben. Ein Retest bestätigt die Korrekturen, und das Portal geht ohne diese Altlasten online.
Warum ist das für Unternehmen wichtig?
Ein White-Box-Test nutzt die Testzeit besonders effizient. Das Prüfteam muss nichts mühsam erraten und konzentriert sich auf die eigentliche Prüfung. So werden auch Schwachstellen sichtbar, die ein Angreifer erst nach langer Suche oder mit Insiderwissen finden würde.
Das zählt vor allem bei kritischen Anwendungen mit sensiblen Daten, Zahlungsfunktionen oder Steuerungsaufgaben. Auch Regelwerke sehen Sicherheitstests vor: ISO/IEC 27001:2022 enthält in Anhang A eine Maßnahme zu Sicherheitstests in Entwicklung und Abnahme, und der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen – also vernetzten Geräten und Software – zu regelmäßigen Sicherheitstests. Diese Pflicht gilt ab dem 11. Dezember 2027.
Der Nachteil: Ein White-Box-Test bildet nicht ab, was ein Außenstehender ohne Vorwissen sieht. Wer genau das wissen will, kombiniert ihn mit einem Black-Box-Ansatz.
Worauf Sie achten sollten
- Ziel klären: Wollen Sie möglichst viele Schwachstellen finden oder die Sicht eines externen Angreifers nachstellen? Davon hängt die Testart ab.
- Unterlagen vorbereiten: Stellen Sie aktuelle Dokumentation, Zugänge und den passenden Codestand bereit – veraltete Pläne kosten Testzeit.
- Vertraulichkeit regeln: Vereinbaren Sie vorab, wie Quellcode und Zugangsdaten sicher übergeben, aufbewahrt und gelöscht werden.
- Zeitpunkt wählen: Ideal ist ein Test vor dem Livegang oder nach größeren Änderungen – dann ist die Behebung noch vergleichsweise günstig.
- Kurze Wege schaffen: Benennen Sie Ansprechpersonen aus der Entwicklung, damit Rückfragen schnell geklärt sind.
- Behebung prüfen lassen: Planen Sie nach der Korrektur einen Retest ein, um den bereinigten Stand belegen zu können.
Wie Rootsektor unterstützt
Ob Black-, Grey- oder White-Box: Im Penetration Testing wählen wir die Testart passend zu Ihrem Ziel und Ihrem Prüfgegenstand. White-Box-Tests von Anwendungen lassen sich mit einem Code Review & Reverse Engineering kombinieren. Auf Wunsch unterzeichnen wir vorab eine Vertraulichkeitsvereinbarung. Nach dem Scoping erhalten Sie innerhalb von 24 Stunden (an Werktagen) ein Festpreisangebot – anfragen können Sie es über unser Pentest-Angebot.