Client-side fuzzing is een testtechniek die willekeurige, misvormde of onverwachte gegevens invoert in browsergebaseerde applicaties om beveiligingskwetsbaarheden en bugs te identificeren. Het helpt problemen te ontdekken in invoerverwerking, DOM-manipulatie en JavaScript-uitvoering. Moderne fuzzing-tools combineren vaak willekeurige invoergeneratie met coverage-gestuurde algoritmen om testeffectiviteit te maximaliseren.
Fuzzing is een geautomatiseerde testtechniek die een programma grote hoeveelheden willekeurige, misvormde of opzettelijk onverwachte invoer voert om te zien wat er breekt. Toegepast op de client-side richt het zich op de browser en op browsergebaseerde applicaties: HTML- en CSS-parsers, de JavaScript-engine, DOM-API's, image- en fontdecoders, en de invoerverwerkingscode van webapps. Een fuzzer genereert of muteert testgevallen, voert ze uit en let op crashes, hangs, geheugenfouten of assertion-fouten die op een bug wijzen. Moderne fuzzers zijn coverage-gestuurd: ze instrumenteren de code en geven de voorkeur aan invoer die nieuwe uitvoeringspaden bereikt, zodat ze gestaag meer van het programma verkennen dan blind willekeurig testen zou doen.
Fuzzing is een van de meest productieve manieren om ernstige bugs te vinden voordat aanvallers dat doen. Browserleveranciers voeren continu grootschalige fuzzing uit om geheugencorruptiefouten in engines en parsers bloot te leggen, en dezelfde technieken gebruiken aanvallers en onderzoekers om exploiteerbare zero-days te ontdekken. Voor ontwikkelaars van webapplicaties brengt het fuzzen van invoerverwerkers en client-side parsers randgevallen aan het licht, zoals misvormde gegevens die DOM-gebaseerde XSS of crashes veroorzaken, die op voorbeelden gebaseerde tests missen. Omdat het invoer verkent die een mens nooit zou bedenken, vindt fuzzing keer op keer gebreken in volwassen, goed gecontroleerde code, en daarom is het een standaardonderdeel van veilige ontwikkeling en kwetsbaarheidsonderzoek.
Behandel fuzzing als onderdeel van een veilige ontwikkelcyclus in plaats van als eenmalige actie. Kies coverage-gestuurde tools, geef ze een goed corpus aan seed-invoer en een doel dat luid faalt (assertions plus sanitizers zoals ASan voor native code), en laat ze continu draaien zodat nieuwe code steeds wordt getest. Combineer fuzzing met sanitizers om stille geheugenfouten op te sporen, en triageer en fix elke reproduceerbare crash, want een crash markeert vaak een exploiteerbare situatie. Fuzz voor webapps alle code die onvertrouwde invoer parseert en combineer dat met statische analyse en codereview. Fuzzing vult monitoring aan van wat third-party code daadwerkelijk in productie doet, maar vervangt het niet.
Beide gebruiken dezelfde techniek. Verdedigers fuzzen hun eigen software om bugs te vinden en te verhelpen vóór release, terwijl aanvallers en onderzoekers veelgebruikte software fuzzen om kwetsbaarheden te ontdekken die ze kunnen uitbuiten of melden. De methode is neutraal; de uitkomst hangt af van wie hem uitvoert en wat ze doen met de crashes die ze vinden.
Het is fuzzing die het doel instrumenteert om te meten welke codepaden elke invoer bereikt, en vervolgens invoer prioriteert en muteert die nieuwe paden opent. Deze feedbacklus verkent veel meer van het programma dan willekeurige invoer alleen, en vindt diepere bugs sneller. AFL en libFuzzer zijn bekende voorbeelden.
We answer client-side security questions every day. Bring yours.