Fuzz-infrastructuur / property-based testing voor invoerparsers #1356

New issue

Closed

opened 2026-08-07 22:18:12 +00:00 by brenno · 0 comments

brenno commented

2026-08-07 22:18:12 +00:00

Owner

Wat

Een test-infrastructuur die random en gemuteerde inputs gooit naar de
invoerparsers van OciDeck — de markdown-parser, de zip-decoder, de
veiligheidsscanner, de JSON-decodering van sidecars, de image-decode. Dit is
precies hoe je de gaten vindt die een mens niet verzint: een afgebroken deck,
een diep-geneste JSON, een zip met understated header-grootte, een GIF met
10.000 frames.

Waarom

De huidige tests zijn gericht op specifieke inputs: "geef deze markdown,
verwacht deze slides". Dat bewijst dat het gelukkige pad werkt. Het bewijst
niet dat het ongelukkige pad graceful faalt — en graceful falen bij corrupte
invoer is precies de robustness-eis die voor dit product zwaar weegt.

De issues #1350–#1355 zijn allemaal bevindingen die een fuzzer in minuten
had gevonden: een truncated deck, een diep-geneste JSON, een high-frame-count
GIF. Zonder fuzz-infrastructuur blijven dit handmatige vondsten, en betekent
elke nieuwe parser of invoerpad een nieuw handmatig onderzoek.

Oplossingsrichting

Dart heeft geen native libFuzzer-integratie, maar er zijn twee realistische
benaderingen:

Property-based testing met package:property_based_testing of een
eigen generator: random-bytes, mutaties van geldige bestanden (bytes
flippen, trunceren, herhalen), random JSON-structuren. Draait in de
bestaande flutter test-suite en in CI.
Gefuzzde corpus-tests: neem een set geldige bestanden, muteer ze
automatisch (byte-flip, truncatie, nesting-verdieping), en beweer dat
elke mutatie óf graceful faalt óf een geldig resultaat oplevert — nooit
een crash, nooit een hang.

Begin met de invoerpaden die onvertrouwde data raken:

MarkdownService.parseDeck
FileService.decodePackageEntries
MarkdownSafetyScanner.scan
jsonDecode op sidecars / grafiekdata / OpenKat
CappedImage / image-decode

Organisatie

Dit is geen één-commit-klus. Het is een taak die georganiseerd moet worden:
een keuze voor een framework, een set generators per invoerpad, en een plek
in de CI-pipeline. Maar het is de structurele investering die de handmatige
security-research-rondes overbodig maakt — of tenminste kleiner maakt.

Herkomst

Geïdentificeerd tijdens security research naar defense-in-depth voor OciDeck.
De vijf bevindingen uit deze ronde (#1350–#1355) zijn elk het soort input dat
een fuzzer automatisch had geproduceerd.

## Wat Een test-infrastructuur die random en gemuteerde inputs gooit naar de invoerparsers van OciDeck — de markdown-parser, de zip-decoder, de veiligheidsscanner, de JSON-decodering van sidecars, de image-decode. Dit is precies hoe je de gaten vindt die een mens niet verzint: een afgebroken deck, een diep-geneste JSON, een zip met understated header-grootte, een GIF met 10.000 frames. ## Waarom De huidige tests zijn gericht op specifieke inputs: "geef deze markdown, verwacht deze slides". Dat bewijst dat het gelukkige pad werkt. Het bewijst niet dat het ongelukkige pad graceful faalt — en graceful falen bij corrupte invoer is precies de robustness-eis die voor dit product zwaar weegt. De issues #1350–#1355 zijn allemaal bevindingen die een fuzzer in minuten had gevonden: een truncated deck, een diep-geneste JSON, een high-frame-count GIF. Zonder fuzz-infrastructuur blijven dit handmatige vondsten, en betekent elke nieuwe parser of invoerpad een nieuw handmatig onderzoek. ## Oplossingsrichting Dart heeft geen native libFuzzer-integratie, maar er zijn twee realistische benaderingen: 1. **Property-based testing** met `package:property_based_testing` of een eigen generator: random-bytes, mutaties van geldige bestanden (bytes flippen, trunceren, herhalen), random JSON-structuren. Draait in de bestaande `flutter test`-suite en in CI. 2. **Gefuzzde corpus-tests**: neem een set geldige bestanden, muteer ze automatisch (byte-flip, truncatie, nesting-verdieping), en beweer dat elke mutatie óf graceful faalt óf een geldig resultaat oplevert — nooit een crash, nooit een hang. Begin met de invoerpaden die onvertrouwde data raken: - `MarkdownService.parseDeck` - `FileService.decodePackageEntries` - `MarkdownSafetyScanner.scan` - `jsonDecode` op sidecars / grafiekdata / OpenKat - `CappedImage` / image-decode ## Organisatie Dit is geen één-commit-klus. Het is een taak die georganiseerd moet worden: een keuze voor een framework, een set generators per invoerpad, en een plek in de CI-pipeline. Maar het is de structurele investering die de handmatige security-research-rondes overbodig maakt — of tenminste kleiner maakt. ## Herkomst Geïdentificeerd tijdens security research naar defense-in-depth voor OciDeck. De vijf bevindingen uit deze ronde (#1350–#1355) zijn elk het soort input dat een fuzzer automatisch had geproduceerd.

brenno added the

triage

enhancement

labels

2026-08-07 22:18:12 +00:00

brenno referenced this issue

2026-08-07 22:18:34 +00:00

Corrupt-file-corpus in test-suite (vaste set pathologische bestanden bij elke CI-run) #1357

brenno referenced this issue from a commit

2026-08-08 07:58:34 +00:00

test: corrupt-file corpus + property-based tests + regressietests (#1356, #1357)

brenno referenced this issue