Blackbox vs. Whitebox Penetrationstest: Wie viel soll der Tester wissen?

Was ist der Unterschied?

Der Unterschied ist Information. Bei einem Blackbox-Test bekommen die Tester eine URL, einen IP-Bereich oder ein Gerät im Karton, und sonst nichts: keine Konten, keine Doku, keinen Quellcode. Bevor sie angreifen können, müssen sie herausfinden, was das Ziel ist und wie es funktioniert, so wie ein Außenstehender. Bei einem Whitebox-Test bekommen sie alles, was das Entwicklungsteam hat: Quellcode, Architektur und Bedrohungsmodell, Firmware-Images, Debug-Zugang, Zugangsdaten für jede Rolle und einen Entwickler, der Fragen beantwortet. Greybox liegt dazwischen und ist in der Praxis die häufigste Form: Konten und Doku, aber kein Code.

Mit der Information ändert sich nicht, ob der Tester einen Bug finden kann, sondern wie viele Bugs in die gebuchten Tage passen. Jede Stunde, die ins Raten einer API-Route, ins Durchprobieren einer Rolle oder ins Auslesen der Firmware aus einem Flash-Chip geht, fehlt bei der Autorisierungslogik, der Krypto oder dem Parser, wo die ernsten Findings sitzen. Blackbox misst, was ein Außenstehender in einer bestimmten Zeit sieht. Whitebox misst, was tatsächlich da ist.

Nebeneinander

	Blackbox	Whitebox
Was es findet	Exponierte Dienste, Schwächen ohne Anmeldung, Informationslecks, schwache Defaults, alles, was ohne Wissen erreichbar ist	Logik- und Autorisierungsfehler über Rollen hinweg, Injection in eigenem Code, Krypto-Fehlnutzung, unsichere Parser in Firmware, Secure-Boot-Lücken, fest einprogrammierte Geheimnisse, Designfehler
Was es übersieht	Alles hinter einem Login, den er nicht knackt, alles, was nur mit Kenntnis des Designs erreichbar ist, die meisten Firmware-Interna; die Abdeckung bleibt unbekannt	Wenig innerhalb des Scopes; das Risiko ist, dass Tester der Doku statt dem laufenden System folgen, deshalb enthalten gute Whitebox-Tests weiterhin Blackbox-artiges Probieren
Wer macht es	Tester von außen, oft mit wenig Kontakt zum Team	Tester und Entwicklungsteam gemeinsam, mit Kick-off und Fragen während des Tests
Dauer	Länger für dieselbe Abdeckung, weil die Erkundung Tage frisst; eine typische Buchung endet, bevor die Abdeckung vollständig ist	Kürzer für dieselbe Abdeckung oder mehr Abdeckung in derselben Zeit; eine bis drei Wochen für ein Produkt
Typische Kosten	Gleiche Tagessätze; 6.000 bis 15.000 Euro für eine Webanwendung, typische Spannen für Deutschland und die EU; du zahlst für die Erkundung	Gleiche Tagessätze, mehr davon gehen in Findings; Firmware- und Code-Review können Tage hinzufügen: 15.000 bis 30.000 Euro für ein IoT-Produkt, 20.000 bis 45.000 für ein Steuergerät; kein Angebot
Häufigkeit	Sinnvoll als einmalige Bestandsaufnahme oder nach langer Zeit ohne Tests	Die Regelform: vor dem Launch, nach großen Releases, einmal im Jahr
Verlangt von	Selten vorgeschrieben; manche Kunden verlangen Tests “aus Angreifersicht”	Ebenfalls nicht vorgeschrieben; CRA, ISO 27001, TISAX und OEM-Anforderungen verlangen wirksame Tests, und Whitebox-Berichte lassen sich leichter verteidigen
Ergebnis	Findings plus eine Karte dessen, was der Tester entdecken konnte; was nicht erreicht wurde, bleibt unbekannt	Findings plus eine Liste der geprüften Komponenten mit Begründung; klare Aussage zur Abdeckung

Nimm einen Blackbox-Test, wenn

• deine Frage wirklich lautet: “Was kann ein Fremder in zwei Wochen aus dem Internet?”, etwa bevor du einen Dienst exponierst oder als Bestandsaufnahme nach Jahren ohne Test.
• du gleichzeitig Erkennung und Reaktion deines Betriebsteams testen willst und das Team den Startpunkt der Tester nicht kennen soll. Kombiniere das mit der Frage intern oder extern, und denk an ein Red Team, wenn die Organisation das Ziel ist.
• ein Kunde ausdrücklich eine Blackbox-Perspektive verlangt, etwa als zweite Meinung nach Whitebox-Tests.
• der Hersteller eines Fremdprodukts dir nichts anderes gibt. Dann ist Blackbox keine Wahl, sondern die einzige Option, und der Bericht sollte das sagen.

Nimm einen Whitebox-Test, wenn

• du ein Produkt auslieferst: IoT-Gerät, Steuergerät, Maschine, Mobile App, SaaS. Die ernsten Findings sitzen in Firmware, Protokoll-Parsern, Boot-Ketten und Autorisierungslogik, und nur Code und Doku machen sie in der gebuchten Zeit erreichbar.
• du Audit-Nachweise mit Aussage zur Abdeckung brauchst. “Wir haben diese 14 Komponenten geprüft, das haben wir gefunden und das nicht” ist, was eine CRA-Konformitätsbewertung, ein OEM oder ein ISO-27001-Auditor lesen will.
• dein Budget begrenzt ist. Das klingt verkehrt, aber Whitebox liefert mehr Findings pro Euro, weil die Tester das Raten überspringen.
• du Fixes willst, nicht nur Findings. Ein Tester, der den Code gelesen hat, zeigt auf die Zeile, und der Entwickler fixt sie am selben Nachmittag.

In den meisten Fällen ist Whitebox oder Greybox die bessere Wahl. Blackbox ist das richtige Werkzeug für eine enge Frage, nicht der Standard.

Beides zusammen

Die meisten guten Projekte sind beides. Die Tester starten ein bis zwei Tage Blackbox, um zu sehen, was ein Außenstehender sieht, und die Lecks zu fangen, die die Doku verdeckt, und wechseln dann für die restlichen Tage zu Whitebox, um in die Tiefe zu gehen. Der Bericht trennt beides: was von außen ohne Wissen erreichbar war und was mit Wissen gefunden wurde. So bekommst du Angreifersicht und vollständige Abdeckung aus einem Projekt.

Zyberum testet Blackbox, Greybox und Whitebox und empfiehlt für fast jedes Produkt und jede Anwendung Greybox oder Whitebox. Wir unterschreiben eine NDA, bevor wir Code oder Firmware bekommen, halten Kundenmaterial auf eigener Infrastruktur und schicken nichts davon an einen Online-KI-Dienst. Wenn du aus einem bestimmten Grund Blackbox willst, machen wir das und schreiben in den Bericht, was diese Wahl ungesehen gelassen hat.