Wikisage, de vrije encyclopedie van de tweede generatie, is digitaal erfgoed
Wikisage is op 1 na de grootste internet-encyclopedie in het Nederlands. Iedereen kan de hier verzamelde kennis gratis gebruiken, zonder storende advertenties. De Koninklijke Bibliotheek van Nederland heeft Wikisage in 2018 aangemerkt als digitaal erfgoed.
- Wilt u meehelpen om Wikisage te laten groeien? Maak dan een account aan. U bent van harte welkom. Zie: Portaal:Gebruikers.
- Bent u blij met Wikisage, of wilt u juist meer? Dan stellen we een bescheiden donatie om de kosten te bestrijden zeer op prijs. Zie: Portaal:Donaties.
Fuzz-testen: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
(https://nl.wikipedia.org/w/index.php?title=Fuzz-testen&diff=cur&oldid=42761723 - Wicoby - 15 dec 2014) |
(https://nl.wikipedia.org/w/index.php?title=Fuzz-testen&oldid=45168793) |
||
| (Een tussenliggende versie door dezelfde gebruiker niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
[[File:Binary executable file2.png|thumb|Een voorbeeld van machinetaal, in hexadecimale cijfers | [[File:Binary executable file2.png|thumb|Een voorbeeld van machinetaal, in hexadecimale cijfers. Deze taal kan de processor van een computer meteen uitvoeren. Software wordt meestal niet meer in deze taal geschreven. Een van de eerste fuzzingmethodes was hierop gebaseerd.]] | ||
'''Fuzzing''' of '''fuzzing-testen''' is een techniek voor het [[Testen (software)|testen van software]] die ongeldige, onverwachte of willekeurige data invoert in een [[ | '''Fuzzing''' of '''fuzzing-testen''' is een techniek voor het [[Testen (software)|testen van software]] die ongeldige, onverwachte of willekeurige data invoert in een [[computerprogramma]]. Het programma wordt in de gaten gehouden voor verwachtingen zoals [[Crash (computer)|crashen]], falende ingebouwde codepredikaten of het vinden van [[Geheugenlek|geheugenlekken]]. Fuzzing wordt vooral gebruikt voor het testen van beveiligingsproblemen in [[software]] of in [[Besturingssysteem|besturingssystemen]]. | ||
== | ==Geschiedenis== | ||
===Ontstaan van de term=== | ===Ontstaan van de term=== | ||
De term "fuzzing" of fuzz-testen" komt origineel van een klasproject in 1988. Deze klas werd gegeven door Barton Miller aan de the University of Wisconsin<ref>Barton Miller (2008). "Preface". In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2</ref><ref>[http://pages.cs.wisc.edu/~bart/fuzz/ "Fuzz Testing of Application Reliability"]. University of Wisconsin-Madison. Opgehaald 8-12-2014.</ref>. Het klasproject ontwikkelde een | De term "fuzzing" of fuzz-testen" komt origineel van een klasproject in 1988. Deze klas werd gegeven door [[Barton Miller]] aan de the University of Wisconsin<ref>Barton Miller (2008). "Preface". In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2</ref><ref>[http://pages.cs.wisc.edu/~bart/fuzz/ "Fuzz Testing of Application Reliability"]. University of Wisconsin-Madison. Opgehaald 8-12-2014.</ref>. Het klasproject ontwikkelde een programma (fuzzer) om de betrouwbaarheid van [[Unix]]-programma's te testen. | ||
De test werd herhaald in 1995. Toen werd de test uitgebreid om | De test werd herhaald in 1995. Toen werd de test uitgebreid om op [[GUI]] gebaseerde tools (zoals bijvoorbeeld het [[X Window System]]), [[Netwerkprotocol|netwerkprotocollen]] en systeembibliotheek [[Application programming interface|API's]] te testen. Testen nadien concentreerden zich op commando- en [[GUI]]-gebaseerde applicaties van zowel [[Windows]] als [[MAC OS X|Mac OS X]]. | ||
===Vroegere voorbeelden=== | ===Vroegere voorbeelden=== | ||
* Een van de eerste voorbeelden van fuzzing | * Een van de eerste voorbeelden van fuzzing dateert van 1983. Steve Capps ontwikkelde een [[Macintosh (computer)|Macintosh]] applicatie genoemd [http://www.folklore.org/StoryView.py?project=Macintosh&story=Monkey_Lives.txt&characters=Steve%20Capps "the monkey"]. De applicatie maakte gebruik van journaling codes om willekeurige data in te brengen in Mac-programma's. Het werd gebruikt om [[bugs]] te testen in MacPaint<ref>[http://crashme.codeplex.com/ "Macintosh Stories: Monkey Lives"]. Folklore.org. 1999-02-22. Opgehaald 8-12-2014.</ref>. | ||
* Een ander voorbeeld van fuzz-test-gereedschap was [http://crashme.codeplex.com/ crashme] | * Een ander voorbeeld van fuzz-test-gereedschap was [http://crashme.codeplex.com/ crashme] uit 1991. Het was bedoeld om de robuustheid van Unix en Unix-achtige besturingssystemen te testen door het uitvoeren van willekeurige machine-instructies<ref>[http://crashme.codeplex.com/ "crashme"]. CodePlex. Retrieved 2012-06-26.</ref>. | ||
==Technieken== | ==Technieken== | ||
=== | ===Twee categorieën=== | ||
De fuzzing-programma's | De fuzzing-programma's bestaan in 2 categorieën: | ||
# Op mutatie | # Op mutatie gebaseerde fuzzers muteren bestaande voorbeelddata om nieuwe data te creëren. | ||
# Op generatie | # Op generatie gebaseerde fuzzers definiëren nieuwe testdata op basis van modellen van de input. | ||
===Verschillende vormen=== | ===Verschillende vormen=== | ||
[[Bestand:Mailman-commandlineinterface.png|thumb|270px|right|Voorbeeld van command-line-interface]] | [[Bestand:Mailman-commandlineinterface.png|thumb|270px|right|Voorbeeld van command-line-interface]] | ||
De simpelste vorm van fuzzing is het '''zenden''' van een '''willekeurige stroom bits naar de software''', als: [[Command-line-interface]], als willekeurig gemuteerde protocolpakketten of als [[Evenement|evenementen]]. Deze techniek van willekeurige data te zenden, blijft een krachtig middel om [[ | De simpelste vorm van fuzzing is het '''zenden''' van een '''willekeurige stroom bits naar de software''', als: [[Command-line-interface]], als willekeurig gemuteerde protocolpakketten of als [[Evenement|evenementen]]. Deze techniek van willekeurige data te zenden, blijft een krachtig middel om [[bugs]] te vinden in [[Command-line-interface]], [[Netwerkprotocol|netwerkprotocollen]] en op GUI-gebaseerde applicaties en diensten. Dit valt dus onder de op generatie-gebaseerde fuzzers. | ||
Een andere veel voorkomende gemakkelijke techniek is het '''muteren van bestaande input''' ( | Een andere veel voorkomende gemakkelijke techniek is het '''muteren van bestaande input''' (bijv. bestanden van een [[integratietest]]) door bits willekeurig om te draaien of door blokken van het bestand te verplaatsen. Echter, de meest succesvolle fuzzers hebben een gedetailleerde kennis over het formaat of het protocol dat wordt getest. Dit valt dus onder de op mutatie gebaseerde fuzzers. | ||
Er bestaat ook de '''"smart-fuzzing"-techniek''' ( ook bekend als: robuustheidstest, [[ | Er bestaat ook de '''"smart-fuzzing"-techniek''' (ook bekend als: robuustheidstest, [[syntactische test]], spellingstest of foute (input) injectie). Een op [[Formal specification|specificatie]] gebaseerde fuzzer houdt in dat een volledige reeks van specificaties wordt geschreven in een gereedschap. Dan wordt op model gebaseerde generatietesttechnieken in het volledig aflopen door de specificaties en het toevoegen van abnormaliteiten van de data's inhoud, structuur, berichten en sequenties. | ||
De protocolaandachtigheid kan ook [https://en.wikipedia.org/wiki/Heuristic_%28computer_science%29 heuristisch] gecreëerd worden op basis van voorbeelden door gebruik te maken van tools zoals [https://en.wikipedia.org/wiki/Sequitur_algorithm Sequitur]. Deze fuzzers kunnen testcasussen genereren uit het niets. Of ze kunnen voorbeelden muteren op basis van [https://en.wikipedia.org/wiki/Test_suite test suites] of uit het echt. Ze kunnen zich concentreren op geldige of ongeldige input, met 'bijna volledig geldige' input die de 'diepste' fouten eruit haalt. | De protocolaandachtigheid kan ook [https://en.wikipedia.org/wiki/Heuristic_%28computer_science%29 heuristisch] gecreëerd worden op basis van voorbeelden door gebruik te maken van tools zoals [https://en.wikipedia.org/wiki/Sequitur_algorithm Sequitur]. Deze fuzzers kunnen testcasussen genereren uit het niets. Of ze kunnen voorbeelden muteren op basis van [https://en.wikipedia.org/wiki/Test_suite test suites] of uit het echt. Ze kunnen zich concentreren op geldige of ongeldige input, met 'bijna volledig geldige' input die de 'diepste' fouten eruit haalt. | ||
Er zijn 2 limieten aan op protocol | Er zijn 2 limieten aan op protocol gebaseerde fuzzing gebaseerd op protocolimplementatie van gepubliceerde specificaties: | ||
# Het testen kan niet doorgaan tot de specificaties een relatieve maturiteit hebben, sinds een specificatie een eerste vereiste is om zo'n fuzzer te schrijven. | # Het testen kan niet doorgaan tot de specificaties een relatieve maturiteit hebben, sinds een specificatie een eerste vereiste is om zo'n fuzzer te schrijven. | ||
# Vele bruikbare protocollen zijn [[Octrooi op software|gepatenteerd]] of bevatten gepatenteerde uitbreidingen van gepubliceerde protocollen. Als fuzzing dan enkel gebaseerd is op gepubliceerde specificaties, dan zal de testomvang voor de nieuwe of gepatenteerde protocollen beperkt tot onbestaande zijn <ref>"[https://en.wikipedia.org/wiki/Fuzz_testing Fuzz testing]". Wikipedia.org. Opgehaald 10-12-2014.</ref>. | # Vele bruikbare protocollen zijn [[Octrooi op software|gepatenteerd]] of bevatten gepatenteerde uitbreidingen van gepubliceerde protocollen. Als fuzzing dan enkel gebaseerd is op gepubliceerde specificaties, dan zal de testomvang voor de nieuwe of gepatenteerde protocollen beperkt tot onbestaande zijn <ref name="enwiki">"[https://en.wikipedia.org/wiki/Fuzz_testing Fuzz testing]". Wikipedia.org. Opgehaald 10-12-2014.</ref>. | ||
===Combinatie met andere testtechnieken=== | ===Combinatie met andere testtechnieken=== | ||
Fuzzing kan ook gecombineerd worden met andere technieken. | Fuzzing kan ook gecombineerd worden met andere technieken. | ||
* White-box fuzzing maakt gebruik van [https://en.wikipedia.org/wiki/Symbolic_execution 'symbolische uitvoering'] en van [https://en.wikipedia.org/wiki/Constraint_solving 'verzadigende beperkingen']. | * White-box fuzzing maakt gebruik van [https://en.wikipedia.org/wiki/Symbolic_execution 'symbolische uitvoering'] en van [https://en.wikipedia.org/wiki/Constraint_solving 'verzadigende beperkingen']. | ||
* Evolutionaire fuzzing maakt gebruik van feedback heuristische (e.g. [https://en.wikipedia.org/wiki/Code_coverage code-omvang] in grey-box harnessing) of een gemodelleerde aanvallers gedrag in black-box harnessing)om effectief de aanpak van [https://en.wikipedia.org/wiki/Exploratory_testing verkennende testen] te automatiseren<ref | * Evolutionaire fuzzing maakt gebruik van feedback heuristische (e.g. [https://en.wikipedia.org/wiki/Code_coverage code-omvang] in grey-box harnessing) of een gemodelleerde aanvallers gedrag in black-box harnessing)om effectief de aanpak van [https://en.wikipedia.org/wiki/Exploratory_testing verkennende testen] te automatiseren<ref name="enwiki" />. | ||
==Gebruik== | ==Gebruik== | ||
===Methodiek=== | ===Methodiek=== | ||
Fuzz-testen wordt vaak gebruikt als een [[ | Fuzz-testen wordt vaak gebruikt als een [[blackboxtest]] in grote softwareprojecten, waar er een budget bestaat om [[testtool]] te ontwikkelen. Fuzz-testen biedt een [[kosten-batenanalyse]] voor vele programma's. | ||
De techniek kan slechts een aselecte steekproef voorzien van het systeems gedrag. En in veel gevallen kan het slagen van een fuzz-test alleen aantonen dat een stukje software uitzonderingen aankan zonder te [[Crash (computer)|crashen]], in plaats van correct gedrag. Dit betekent fuzz-testen algehele kwaliteit verzekert, in plaats van een bug-finding tool, en geen vervanging is voor uitgebreide tests of [[formele methoden]]. | De techniek kan slechts een aselecte steekproef voorzien van het systeems gedrag. En in veel gevallen kan het slagen van een fuzz-test alleen aantonen dat een stukje software uitzonderingen aankan zonder te [[Crash (computer)|crashen]], in plaats van correct gedrag. Dit betekent fuzz-testen algehele kwaliteit verzekert, in plaats van een bug-finding tool, en geen vervanging is voor uitgebreide tests of [[formele methoden]]. | ||
Als een ruw meetinstrument voor betrouwbaarheid kan fuzzing voorstellen welke delen van het programma bijzondere aandacht moet krijgen in de vorm van een [https://en.wikipedia.org/wiki/Code_audit code audit], [https://en.wikipedia.org/wiki/Static_program_analysis statische code analyse] of gedeeltelijke [https://en.wikipedia.org/wiki/Rewrite_(programming) herschrijving]<ref | Als een ruw meetinstrument voor betrouwbaarheid kan fuzzing voorstellen welke delen van het programma bijzondere aandacht moet krijgen in de vorm van een [https://en.wikipedia.org/wiki/Code_audit code audit], [https://en.wikipedia.org/wiki/Static_program_analysis statische code analyse] of gedeeltelijke [https://en.wikipedia.org/wiki/Rewrite_(programming) herschrijving]<ref name="enwiki" />. | ||
===Soorten bugs=== | ===Soorten bugs=== | ||
[[Image:Winpdb-1.3.6.png|thumb|300px|een voorbeeld van een programma dat zichzelf debugt]] | [[Image:Winpdb-1.3.6.png|thumb|300px|een voorbeeld van een programma dat zichzelf debugt]] | ||
* Evenals het testen voor volledige [[Crash (computer)|crashes]], kunnen fuzz-testen ook gebruikt worden om [[ | * Evenals het testen voor volledige [[Crash (computer)|crashes]], kunnen fuzz-testen ook gebruikt worden om [[bugs]] te vinden zoals mislukte beweringen en [[Geheugenlek|geheugenlekken]] (indien gekoppeld met een geheugen[[debugger]]). De methode is handig voor grote toepassingen, waarbij eender welke bug de geheugenveiligheid kan beïnvloeden heel waarschijnlijk een ernstige kwetsbaarheid is. | ||
* Sinds fuzzing vaak ongeldige invoer genereert, wordt het gebruikt voor het testen van foutieve afhandelingsroutines, die belangrijk zijn voor software die zijn input niet kan beheersen. Eenvoudige fuzzing kan van gezien worden als een manier om negatieve testen te automatiseren. | * Sinds fuzzing vaak ongeldige invoer genereert, wordt het gebruikt voor het testen van foutieve afhandelingsroutines, die belangrijk zijn voor software die zijn input niet kan beheersen. Eenvoudige fuzzing kan van gezien worden als een manier om negatieve testen te automatiseren. | ||
* Fuzzing kan ook een aantal vormen van "correctheid"[[ | * Fuzzing kan ook een aantal vormen van "correctheid"[[bugs]] vinden. Zo kan het worden gebruikt om foute [[serialisatie]][[bugs]]te vinden door het klagen wanneer programma's [https://en.wikipedia.org/wiki/Serializer serializer] iets uitzendt dat het programma's [[parser]] verwerpt. Het kan ook onbedoelde verschillen tussen twee versies van een programma vinden of tussen twee [[Implementatie|implementaties]] van dezelfde [https://en.wikipedia.org/wiki/Formal_specification%20specificatie specificatie]. | ||
==Voortplanting en isolatie== | ==Voortplanting en isolatie== | ||
| Regel 62: | Regel 61: | ||
===Voordelen=== | ===Voordelen=== | ||
[[File:CVE-2014-0160.png|thumb|Een voorbeeld van een bug]] | [[File:CVE-2014-0160.png|thumb|Een voorbeeld van een bug]] | ||
* [[ | * [[bugs]] gevonden met fuzz-testen zijn soms ernstig, uitbuitbare [[bugs]] die een aanvaller kan gebruiken. Ontdekkingen gebeuren regelmatig omdat de fuzz-testen bekend zijn. Aanvallers gebruiken dezelfde technieken om software te misbruiken. Dit is een voordeel ten opzichte van binaire of brontest en de foute (input) injecties. | ||
* Fuzz-testen | * Fuzz-testen verbeteren de softwarebeveiliging en de softwareveiligheid omdat het vergissingen en gebreken vindt die mensen niet vinden. | ||
===Nadelen=== | ===Nadelen=== | ||
* Het | * Het probleem met fuzzing om programmafouten te vinden is dat het slechts eenvoudige fouten vindt. Het uitvoeren van de test wordt steeds moeilijker en elke fuzzer neemt snelkoppelingen om iets interessants te vinden. Een primitieve fuzzer kan een slechte [[code-omvang]] hebben als de input een [[Controlecijfer|controlesom]] bevat dat niet aangepast is om willekeurige veranderingen aan te kunnen. Code-omvanginstrumenten worden vaak gebruikt om in te schatten hoe "goed" een fuzzer werkt. Van elke fuzzer kan worden verwacht dat ze een andere set van [[bugs]] vinden. | ||
* De willekeur van inputs gebruikt in fuzzing wordt vaak gezien als een nadeel, omdat het vangen van een [[Grenswaardenanalyse|grenswaarde]]omstandigheid met willekeurige input | * De willekeur van inputs gebruikt in fuzzing wordt vaak gezien als een nadeel, omdat het vangen van een [[Grenswaardenanalyse|grenswaarde]]omstandigheid met willekeurige input onwaarschijnlijk is. Maar de meeste fuzzers vandaag de dag lossen dit probleem op met behulp van [[deterministisch algoritme|deterministische algoritmen]] op basis van de gebruiker zijn inputs. | ||
{{Bron|bronvermelding= | |||
{{Bronvermelding anderstalige Wikipedia|taal=en|titel=Fuzz testing|oldid=621009604|datum=20141215}} | |||
{{References}} {{Wikidata|Q1189053}}}} | |||
[[Categorie:Softwaretest]] | |||
Huidige versie van 6 nov 2015 om 08:31
Fuzzing of fuzzing-testen is een techniek voor het testen van software die ongeldige, onverwachte of willekeurige data invoert in een computerprogramma. Het programma wordt in de gaten gehouden voor verwachtingen zoals crashen, falende ingebouwde codepredikaten of het vinden van geheugenlekken. Fuzzing wordt vooral gebruikt voor het testen van beveiligingsproblemen in software of in besturingssystemen.
Geschiedenis
Ontstaan van de term
De term "fuzzing" of fuzz-testen" komt origineel van een klasproject in 1988. Deze klas werd gegeven door Barton Miller aan de the University of Wisconsin[1][2]. Het klasproject ontwikkelde een programma (fuzzer) om de betrouwbaarheid van Unix-programma's te testen. De test werd herhaald in 1995. Toen werd de test uitgebreid om op GUI gebaseerde tools (zoals bijvoorbeeld het X Window System), netwerkprotocollen en systeembibliotheek API's te testen. Testen nadien concentreerden zich op commando- en GUI-gebaseerde applicaties van zowel Windows als Mac OS X.
Vroegere voorbeelden
- Een van de eerste voorbeelden van fuzzing dateert van 1983. Steve Capps ontwikkelde een Macintosh applicatie genoemd "the monkey". De applicatie maakte gebruik van journaling codes om willekeurige data in te brengen in Mac-programma's. Het werd gebruikt om bugs te testen in MacPaint[3].
- Een ander voorbeeld van fuzz-test-gereedschap was crashme uit 1991. Het was bedoeld om de robuustheid van Unix en Unix-achtige besturingssystemen te testen door het uitvoeren van willekeurige machine-instructies[4].
Technieken
Twee categorieën
De fuzzing-programma's bestaan in 2 categorieën:
- Op mutatie gebaseerde fuzzers muteren bestaande voorbeelddata om nieuwe data te creëren.
- Op generatie gebaseerde fuzzers definiëren nieuwe testdata op basis van modellen van de input.
Verschillende vormen
De simpelste vorm van fuzzing is het zenden van een willekeurige stroom bits naar de software, als: Command-line-interface, als willekeurig gemuteerde protocolpakketten of als evenementen. Deze techniek van willekeurige data te zenden, blijft een krachtig middel om bugs te vinden in Command-line-interface, netwerkprotocollen en op GUI-gebaseerde applicaties en diensten. Dit valt dus onder de op generatie-gebaseerde fuzzers.
Een andere veel voorkomende gemakkelijke techniek is het muteren van bestaande input (bijv. bestanden van een integratietest) door bits willekeurig om te draaien of door blokken van het bestand te verplaatsen. Echter, de meest succesvolle fuzzers hebben een gedetailleerde kennis over het formaat of het protocol dat wordt getest. Dit valt dus onder de op mutatie gebaseerde fuzzers.
Er bestaat ook de "smart-fuzzing"-techniek (ook bekend als: robuustheidstest, syntactische test, spellingstest of foute (input) injectie). Een op specificatie gebaseerde fuzzer houdt in dat een volledige reeks van specificaties wordt geschreven in een gereedschap. Dan wordt op model gebaseerde generatietesttechnieken in het volledig aflopen door de specificaties en het toevoegen van abnormaliteiten van de data's inhoud, structuur, berichten en sequenties.
De protocolaandachtigheid kan ook heuristisch gecreëerd worden op basis van voorbeelden door gebruik te maken van tools zoals Sequitur. Deze fuzzers kunnen testcasussen genereren uit het niets. Of ze kunnen voorbeelden muteren op basis van test suites of uit het echt. Ze kunnen zich concentreren op geldige of ongeldige input, met 'bijna volledig geldige' input die de 'diepste' fouten eruit haalt.
Er zijn 2 limieten aan op protocol gebaseerde fuzzing gebaseerd op protocolimplementatie van gepubliceerde specificaties:
- Het testen kan niet doorgaan tot de specificaties een relatieve maturiteit hebben, sinds een specificatie een eerste vereiste is om zo'n fuzzer te schrijven.
- Vele bruikbare protocollen zijn gepatenteerd of bevatten gepatenteerde uitbreidingen van gepubliceerde protocollen. Als fuzzing dan enkel gebaseerd is op gepubliceerde specificaties, dan zal de testomvang voor de nieuwe of gepatenteerde protocollen beperkt tot onbestaande zijn [5].
Combinatie met andere testtechnieken
Fuzzing kan ook gecombineerd worden met andere technieken.
- White-box fuzzing maakt gebruik van 'symbolische uitvoering' en van 'verzadigende beperkingen'.
- Evolutionaire fuzzing maakt gebruik van feedback heuristische (e.g. code-omvang in grey-box harnessing) of een gemodelleerde aanvallers gedrag in black-box harnessing)om effectief de aanpak van verkennende testen te automatiseren[5].
Gebruik
Methodiek
Fuzz-testen wordt vaak gebruikt als een blackboxtest in grote softwareprojecten, waar er een budget bestaat om testtool te ontwikkelen. Fuzz-testen biedt een kosten-batenanalyse voor vele programma's.
De techniek kan slechts een aselecte steekproef voorzien van het systeems gedrag. En in veel gevallen kan het slagen van een fuzz-test alleen aantonen dat een stukje software uitzonderingen aankan zonder te crashen, in plaats van correct gedrag. Dit betekent fuzz-testen algehele kwaliteit verzekert, in plaats van een bug-finding tool, en geen vervanging is voor uitgebreide tests of formele methoden.
Als een ruw meetinstrument voor betrouwbaarheid kan fuzzing voorstellen welke delen van het programma bijzondere aandacht moet krijgen in de vorm van een code audit, statische code analyse of gedeeltelijke herschrijving[5].
Soorten bugs
- Evenals het testen voor volledige crashes, kunnen fuzz-testen ook gebruikt worden om bugs te vinden zoals mislukte beweringen en geheugenlekken (indien gekoppeld met een geheugendebugger). De methode is handig voor grote toepassingen, waarbij eender welke bug de geheugenveiligheid kan beïnvloeden heel waarschijnlijk een ernstige kwetsbaarheid is.
- Sinds fuzzing vaak ongeldige invoer genereert, wordt het gebruikt voor het testen van foutieve afhandelingsroutines, die belangrijk zijn voor software die zijn input niet kan beheersen. Eenvoudige fuzzing kan van gezien worden als een manier om negatieve testen te automatiseren.
- Fuzzing kan ook een aantal vormen van "correctheid"bugs vinden. Zo kan het worden gebruikt om foute serialisatiebugste vinden door het klagen wanneer programma's serializer iets uitzendt dat het programma's parser verwerpt. Het kan ook onbedoelde verschillen tussen twee versies van een programma vinden of tussen twee implementaties van dezelfde specificatie.
Voortplanting en isolatie
Testcasevermindering is het proces van minimale testcases te extraheren uit een originele testcase[6][7]. Testcasevermindering kan manueel worden gedaan, of met behulp van softwaretools, en meestal gaat om een verdeel-en-heers-algoritme , waarin delen van de test één voor één verwijderd worden, totdat alleen de essentiële kern van de testcase blijft.
Om fouten te kunnen reproduceren, zal de fuzzing-software vaak de invoergegevens dat ze produceert bijhouden, meestal voordat ze het toepast in de software. Als de computer volledig crasht bijft de data bewaart. Als de fuzz-stroom pseudowillekeurig nummergegenereerd is, kan de zaadwaarde worden opgeslagen om de fuzz-poging te reproduceren. Zodra een bug wordt gevonden, zullen sommige fuzzing-software helpen om een testcase te bouwen, die wordt gebruikt voor debugging, gebruik makend van testcaseverminderingshulpmiddelen zoals Delta of Lithium.
Voor- en nadelen
Voordelen
- bugs gevonden met fuzz-testen zijn soms ernstig, uitbuitbare bugs die een aanvaller kan gebruiken. Ontdekkingen gebeuren regelmatig omdat de fuzz-testen bekend zijn. Aanvallers gebruiken dezelfde technieken om software te misbruiken. Dit is een voordeel ten opzichte van binaire of brontest en de foute (input) injecties.
- Fuzz-testen verbeteren de softwarebeveiliging en de softwareveiligheid omdat het vergissingen en gebreken vindt die mensen niet vinden.
Nadelen
- Het probleem met fuzzing om programmafouten te vinden is dat het slechts eenvoudige fouten vindt. Het uitvoeren van de test wordt steeds moeilijker en elke fuzzer neemt snelkoppelingen om iets interessants te vinden. Een primitieve fuzzer kan een slechte code-omvang hebben als de input een controlesom bevat dat niet aangepast is om willekeurige veranderingen aan te kunnen. Code-omvanginstrumenten worden vaak gebruikt om in te schatten hoe "goed" een fuzzer werkt. Van elke fuzzer kan worden verwacht dat ze een andere set van bugs vinden.
- De willekeur van inputs gebruikt in fuzzing wordt vaak gezien als een nadeel, omdat het vangen van een grenswaardeomstandigheid met willekeurige input onwaarschijnlijk is. Maar de meeste fuzzers vandaag de dag lossen dit probleem op met behulp van deterministische algoritmen op basis van de gebruiker zijn inputs.
Bronvermelding
Bronnen, noten en/of referenties:
- º Barton Miller (2008). "Preface". In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2
- º "Fuzz Testing of Application Reliability". University of Wisconsin-Madison. Opgehaald 8-12-2014.
- º "Macintosh Stories: Monkey Lives". Folklore.org. 1999-02-22. Opgehaald 8-12-2014.
- º "crashme". CodePlex. Retrieved 2012-06-26.
- ↑ 5,0 5,1 5,2 "Fuzz testing". Wikipedia.org. Opgehaald 10-12-2014.
- º "Test Case Reduction". Opgehaald 10-12-2014.
- º "IBM Test Case Reduction Techniques". Opgehaald 12-12-2014.
Intertaalkoppelingen via Wikidata (via reasonator)