Fuzz Testing
Auerbach Publications eBooks · 2007
Cited by 0
Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.
About 932 papers for “Fuzz testing”
Auerbach Publications eBooks · 2007
Cited by 0
George Klees, Andrew Ruef, Benji Cooper et al. · 2018
Fuzz testing has enjoyed great success at discovering security critical bugs in real software. Recently, researchers have devoted significant effort to devising new fuzzing techniques, strategies, and algorithms. Such new ideas are primarily evaluated experimentally so an important question is: What experimental setup is needed to produce trustworthy results? We surveyed the recent research literature and assessed the experimental evaluations carried out by 32 fuzzing papers. We found problems in every evaluation we considered. We then performed our own extensive experimental evaluation using an existing fuzzer. Our results showed that the general problems we found in existing experimental evaluations can indeed translate to actual wrong or misleading assessments. We conclude with some guidelines that we hope will help improve experimental evaluations of fuzz testing algorithms, making reported results more robust.
Cited by 580Open access
Allen D. Householder, Jonathan M. Foote, Allen D. Householder et al. · 2012
FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for the SEI Administrative Agent
Cited by 0
Jonathan Knudsen, Mikko Varpiola · 2013
Fuzz testing is an industry-standard technique for locating unknown vulnerabilities in software. Fuzz testing is mandatory portion of many modern secure software development life cycles (SDLCs), such as those used at Adobe, Cisco Systems and Microsoft. This document provides a framework to assess the maturity of your processes, software, systems and devices. At the heart of this document is a maturity model for fuzz testing that maps metrics and procedures of effective fuzz testing to maturity levels. The maturity model is a lingua franca for talking about fuzzing, allowing different organizations to communicate effectively about fuzzing without being tied to specific tools. A key benefit of this model is that it enables organizations to make informed decisions about the time and resources needed to perform fuzz testing as part of product development or product verification. Furthermore, it helps you plan and understand where you are with your fuzzing efforts. Even if your product development, validation, or acceptance testing procedures do not adhere to one of the aforementioned SDLCs, fuzzing remains a crucial technique for locating vulnerabilities in software. This version of FTMM focuses on defining a framework which allows comparing and exchanging information about fuzzing using measurable and interchangeable metrics. It does not define or mandate how any particular organization chooses to implement it or measure it.
Cited by 0
Ina Schieferdecker · 2012
The European ITEA2 project DIAMONDS (Development and Industrial Application of Multi-Domain Security Testing Technologies) develops under the direction of Fraunhofer FOKUS, Berlin efficient and automated security test methods for security-critical, networked systems in various industrial domains such as industrial automation, banking and telecommunications. DIAMONDS develops methods to design objective, transparent, repeatable, and automated security tests that focus on system specifications and related risks. The project goals include the development of a security test pattern catalogue and the development of model-based security testing techniques such as risk-based testing and model-based fuzz testing. The project results are made available through publications and contributions to the standardization at ETSI and other standardization bodies. The presentation focusses on model-based fuzz testing, reviews the state of the art, compare it to similar approaches such as mutation testing, and presents first results on behaviour fuzzing for security testing.
Cited by 11
Fatmah Assiri · OSF Preprints (OSF Preprints) · 2023
This is a list of the papers used in the review study for mutation operation selection optimization in fuzz testing
Cited by 0
Tran Chi Thien · Программирование / Programming and Computer Software · 2025
Fuzzing remains to be the most effective method for identifying security vulnerabilities in software. In the context of fuzz testing, the fuzzer supplies varied inputs to fuzz targets, which are designed to comprehensively exercise critical sections of the client code. Various studies have focused on optimizing and developing advanced fuzzers, such as AFL++, libFuzzer, Hongfuzz, syzkaller, ISP-Fuzzer, which have substantially enhanced vulnerability detection in widely used software and libraries. Nevertheless, achieving greater coverage necessitates improvements in both the quality and quantity of fuzz targets. In large-scale software projects and libraries — characterized by numerous user defined functions and data types — manual creation of fuzz targets is both labor-intensive and time-consuming. This challenge underscores the need for automated techniques not only to generate fuzz targets but also to streamline the execution and analysis of their results. In this paper, we introduce an approach to improving fuzz target generation through static analysis of library source code. The proposed method encompasses several key aspects: it analyzes source code structures to accurately construct function calls and generate fuzz targets; it maps fuzzer input data to the corresponding function parameters; it synthesizes compilation information for the fuzz targets; and it automatically collects and analyzes execution results. Experimental results on C/C++ libraries demonstrate that this approach outperforms several existing methods in the field.
Cited by 0
Chi Thien Tran · Programming and Computer Software · 2025
Fuzzing remains to be the most effective method for identifying security vulnerabilities in software. In the context of fuzz testing, the fuzzer supplies varied inputs to fuzz targets, which are designed to comprehensively exercise critical sections of the client code. Various studies have focused on optimizing and developing advanced fuzzers, such as AFL++, libFuzzer, Honggfuzz, syzkaller, ISP-Fuzzer, which have substantially enhanced vulnerability detection in widely used software and libraries. Nevertheless, achieving greater coverage necessitates improvements in both the quality and quantity of fuzz targets. In large-scale software projects and libraries–characterized by numerous user defined functions and data types–manual creation of fuzz targets is both labor-intensive and time-consuming. This challenge underscores the need for automated techniques not only to generate fuzz targets but also to streamline the execution and analysis of their results. In this paper, we introduce an approach to improving fuzz target generation through static analysis of library source code. The proposed method encompasses several key aspects: it analyzes source code structures to accurately construct function calls and generate fuzz targets; it maps fuzzer input data to the corresponding function parameters; it synthesizes compilation information for the fuzz targets; and it automatically collects and analyzes execution results. Experimental results on C/C++ libraries demonstrate that this approach outperforms several existing methods in the field.
Cited by 0Open access
Chi Thien. Tran · arXiv (Cornell University) · 2026
Fuzzing continues to be the most effective method for identifying security vulnerabilities in software. In the context of fuzz testing, the fuzzer supplies varied inputs to fuzz targets, which are designed to comprehensively exercise critical sections of the client code. Various studies have focused on optimizing and developing advanced fuzzers, such as AFL++, libFuzzer, Honggfuzz, syzkaller, ISP-Fuzzer, which have substantially enhanced vulnerability detection in widely used software and libraries. Nevertheless, achieving greater coverage necessitates improvements in both the quality and quantity of fuzz targets. In large-scale software projects and libraries -- characterized by numerous user defined functions and data types -- manual creation of fuzz targets is both labor-intensive and time-consuming. This challenge underscores the need for automated techniques not only to generate fuzz targets but also to streamline the execution and analysis of their results. In this paper, we introduce an approach to improving fuzz target generation through static analysis of library source code. The proposed method encompasses several key aspects: it analyzes source code structures to accurately construct function calls and generate fuzz targets; it maps fuzzer input data to the corresponding function parameters; it synthesizes compilation information for the fuzz targets; and it automatically collects and analyzes execution results. Our findings are demonstrated through the application of this approach to the generation of fuzz targets for C/C++ libraries.
Cited by 0Open access
Henning Siemen, Jonas Lienke, Georg Gläser · 2023
The task of verifying microelectronic hardware designs is as crucial to the design process as it is tedious. Despite numerous helpful methodologies like constraint random testing, it takes an experienced engineer to find hidden bugs and unintended system behavior. Conventional testing approaches are centered on individual test cases in order to test specific scenarios. Analog to the well-established software technique of fuzz-testing, we present What-The-Fuzz (WTF), a coverage-guided mutation-based fuzzer and demonstrate it on an example circuit. Test cases are generated in an automated fashion by consecutively mutating input stimuli, guiding them to achieve increased coverage. In contrast to purely random test cases, we avoid the vast majority of trivial noise-like invalid inputs and focus on test cases that actually result state transitions of the tested device.
Cited by 1
Lin Jiang, Weiyu Dong · 2024
Fuzzing is one of the most effective methods currently available for detecting web vulnerabilities. However, traditional fuzzing suffers from issues such as low coverage and limited diversity in test cases. To address these issues, we propose a way to generate test cases based on dynamic feature libraries and attack models by analysing the characteristics of SQL and XSS. Additionally, we introduce a genetic algorithm to guide the population's evolution by monitoring the state changes of the web application. Furthermore, we improved the selection phase of the genetic algorithm to optimally deform multiple iterations for use cases with low fitness values in order to preserve the population diversity to expand the attack capability of the test cases and based on this the SPAFuzz fuzzy testing tool was implemented. Experimental results show that SPAFuzz is able to detect more network vulnerabilities than Sqlmap and Powerfuzzer.
Cited by 0
Havelund, Klaus · JPL Data · 2025
Testing is in practice commonly performed by executing care-fully planned scripts, which exercise particular planned scenarios. Fuzztesting can be applied as a complementary approach, to exercise a systemoutside the boundaries of the expected. However, fuzz testing can be toorandom. In this work, we explore an approach to fuzz testing using anexpressive temporal logic named MaTL (Matching Temporal Logic) forexpressing constraints on tests, restricting generated tests to only suchthat satisfy the provided constraints. MaTL is a linear temporal logicthat supports future and past time operators and a match constructthat selects argument values from events, similar to pattern matchingin functional programming languages. Constraint solving is performedusing the Z3 SMT solver.
Cited by 0Open access
Ciprian Păduraru, Rareş Cristea, Alin Ştefănescu · Software Impacts · 2024
Low-code and no-code paradigms are accessible, but lack mature testing methods. This gap needs to be addressed as such applications provide a way for stakeholders to interact with or define the requirements of applications in video games, digital twins, and simulations. Blueprints are an example of this paradigm, enabling a visual definition of functionality or requirements. We proposed an open-source tool that uses fuzz testing and applied it to Unreal Engine blueprints. Tests triggered by stakeholder changes are automatically generated, offering support for tuning parameters and optimizing testing time. • A fuzz testing tool for low-code/no-code software blueprints. • Evaluation shows higher component coverage, especially for non-technical features. • Discussing the tool’s potential in other low-code domains (e.g., ML, digital twins, DevOps)
Cited by 0Open access
Juho Myllylahti · 2013
Cited by 1
University of Oulu Repository (University of Oulu) · 2013
Cited by 0
Petar Tsankov, Mohammad Torabi Dashti, David Basin · Repository for Publications and Research Data (ETH Zurich) · 2012
We propose a light-weight, yet effective, technique for fuzz-testing security protocols. Our technique is modular, it exercises (stateful) protocol implementations in depth, and handles encrypted traffic. We use a concrete implementation of the protocol to generate valid inputs, and mutate the inputs using a set of fuzz operators. A dynamic memory analysis tool monitors the execution as an oracle to detect the vulnerabilities exposed by fuzz-testing. We provide the fuzzer with the necessary keys and cryptographic algorithms in order to properly mutate encrypted messages. We present a case study on two widely used, mature implementations of the Internet Key Exchange (IKE) protocol and report on two new vulnerabilities discovered by our fuzz-testing tool. We also compare the effectiveness of our technique to two existing model-based fuzz-testing tools for IKE.
Cited by 37Open access
Bohačík, Antonín, Ilgner, Petr, Fujdiak Radek · Brno University of Technology Digital Library (Brno University of Technology) · 2022
Průmyslové řídicí systémy byly vždy tradičněvelmi izolované a pracovaly s velmi konzistentním datovýmprovozem. Spolu s trendem Průmyslu 4.0 se jejich izolacesnižuje a průmyslové systémy jsou mnohem více propojenys ostatními sítěmi. Velký důraz je v těchto systémechkladen na jejich spolehlivost, ale také na kybernetickoubezpečnost. Článek pojednává o možnostech testovánífuzzingu průmyslových protokolů IEC 104 a široce používanémprotokolu Modbus, jejich bezpečnostních aspektecha strukturách. Je představen nástroj pro fuzzingové testovánítěchto protokolů s cílem odhalit možné zranitelnosti.Podrobně je popsána architektura navrhovaného fuzzeru.Schopnosti fuzzeru jsou pak demonstrovány na testovacímzařízení.
Cited by 0
Liščinský, Matúš · Brno University of Technology Digital Library (Brno University of Technology) · 2019
Fixing one issue sometimes brings another ten to the program. To detect these issues, especially performance issues, we often have to supply the program with input, that forces its worst-case behaviour. A popular solution to automatic inputs generation is so called fuzzing, however, its intention is to find functional bugs. In this work, we aim to construct an automatic generator of inputs whose task will be to trigger performance fluctuations. So we propose to tune fuzzing mutation rules and ways of processing the information about program run, to particularly trigger the performance bugs. We integrate our solution into a performance profile manager Perun, which stores information about every run as a profile and is able to compare these profiles to check for performance change. Therefore we can prove that executing with certain input takes more time or memory. We tested our fuzzer on several artificial projects, which shows its potential with generated inputs that prolong the runtime of the program. Such a solution would allow developers to regularly test every version of a project for performance bugs and avoid them completely by automatically finding new exhausting inputs before release.
Cited by 0
Segedy, Patrik · Brno University of Technology Digital Library (Brno University of Technology) · 2020
Táto práca sa zaoberá fuzz testovaním REST API. Po prezentovaní prehľadu techník používaných pri fuzz testovaní a posúdení aktuálnych nástrojov a výskumu zameraného na REST API fuzz testovanie, sme pristúpili k návrhu a implementácii nášho REST API fuzzeru. Základom nášho riešenia je odvodzovanie závislostí z OpenAPI formátu popisu REST API, umožňujúce stavové testovanie aplikácie. Náš fuzzer minimalizuje počet po sebe nasledujúcich 404 odpovedí od aplikácie a testuje aplikáciu viac do hĺbky. Problém prehľadávania dostupných stavov aplikácie je riešený pomocou usporiadania závislostí tak, aby sa maximalizovala pravdepodobnosť získania potrebných vstupných dát pre povinné parametre, v kombinácii s rozhodovaním, ktoré povinné parametre môžu využívať aj náhodne generované hodnoty. Implementácia je rozšírením Schemathesis projektu, ktorý generuje vstupy za pomoci Hypothesis knižnice. Implementovaný fuzzer je použitý na testovanie Red Hat Insights aplikácie, kde našiel 32 chýb, z čoho jednu chybu je možné reprodukovať len za pomoci stavového testovania.
Cited by 0
Pestrea, Anna · KTH Publication Database DiVA (KTH Royal Institute of Technology) · 2021
In modern society, security has become an increasingly important subject, as technologyhas become an integrated part of everyday life. The security of a system can be tested withthe help of fuzzing, where incoming messages to the system are altered. In this thesis, afuzzer was developed targeting an E-UTRAN Node B (eNB) in the Long-Term Evolution(LTE) landscape. The eNB is current prototype and is from the company Ericsson. Thefuzzer is particularly designed for testing the Medium Access Control (MAC) layer of theeNB. The fuzzer uses a genetic method where all of the fuzzer’s flags (the R, F2, E, LCID, Fand L flags) are triggered during the fuzzing period. Depending on the output of the firstgeneration of fuzzed values, new values are generated either by choosing a value close tothe original value, or by choosing a value that belong to the same subgroup as the originalvalue. Four test cases are made, where first test case is the base line of the program and theother three test cases fuzzes the eNB, using different parts of the fuzzer. The results show that depending on which parts of the fuzzer are used, the connectionbecomes different. For test two and three, the connection became increasingly unstable andmore data was present in the connection. Test case four did not however deviate so muchfrom the baseline, if compared to test two and three.
Cited by 0Open access