Delivering malformed data for fuzz testing to software applications

Systems and methods to deliver malformed data for software application fuzzing are described. In one aspect, a fuzzing engine receives well-formed valid input data from a test automation tool. The received data is for input into a software application to implement a functional test. Responsive to receiving the well-formed valid input data, the fuzzing engine automatically generates corresponding malformed data based on characteristics of the well-formed valid input data. The application is then automatically fuzzed with the malformed data to notify an end-user of any security vulnerabilities in one or more code paths of the application used to process the malformed data.

BACKGROUND

To avoid certain types of security vulnerabilities, computer-program applications should verify that consumed input is well-formed, without making false assumptions about input consistency. Otherwise, security vulnerabilities such as buffer overruns resulting from malformed input and other types of errors may be fatal to proper functioning and results of the application. To locate any such vulnerabilities, software developers often implement “fuzz testing”, or “fuzzing” prior to releasing software. Fuzzing is a software testing technique that typically provides random data (“fuzz”) as computer-program application data inputs to identify access violations and/or buffer overruns (not functional problems). If the application fails in view of such randomly generated data inputs, for example, by crashing, or by failing built-in code assertions, a software developer generally notes and attempts to address the defects. However, conventional software fuzz testing techniques are typically very time consuming and labor intensive, often requiring iterative manual effort and/or use of inefficient automated techniques. For instance, existing fuzzing techniques generally only locate very specific and simple faults, often with poor code coverage. For example, if input includes a checksum which is not properly updated to match other random changes, only the checksum validation code will be verified. Every fuzzer is generally designed to find a different set of vulnerabilities, or bugs.

SUMMARY

Systems and methods to deliver malformed data for software application fuzzing are described. In one aspect, a fuzzing engine receives well-formed valid input data from a test automation tool. The received data is for input into a software application to implement a functional test. Responsive to receiving the well-formed valid input data, the fuzzing engine automatically generates corresponding malformed data based on characteristics of the well-formed valid input data. The application is then automatically fuzzed with the malformed data to notify an end-user of any security vulnerabilities in one or more code paths of the application used to process the malformed data.

DETAILED DESCRIPTION

Overview

Conventional software fuzzing techniques typically deliver malformed inputs to software either by creating a file with malformed content for input into a tested application (e.g., by parsing), or by developing a specific proprietary fuzzing test tool to deliver malformed data at appropriate instances. Providing malformed inputs to software via a file is essentially limited because in certain scenarios not all tested applications are designed to accept input as files. For example to perform fuzzing of a web server fuzzed inputs need to be sent as http requests. Additionally, providing only malformed input via a final may not be sufficient to test all code paths of an application. For example, to reach a particular code path, a software application may need to be brought to one or more required states via configuration operations before the input data can be properly input to the code path for testing. For example to fuzz web server authentication implementation, it should be configured to request authentication. Moreover, developing a specific proprietary fuzzing test tool to input malformed content into software typically requires complex implementation of the application's code to configure tested portions and drive those portions to a target state before the tested portions can be fuzzed. Producing such complex implementations is generally a time consuming and labor intensive task.

Systems and methods to deliver malformed data for fuzz testing software applications are described below. These systems and methods address the described limitations of existing techniques to deliver malformed inputs to a software application to fuzz the software application. Software targeted for fuzzing or being fuzzed is frequently called a “tested application” or “tested software.” To this end, the systems and methods include a fuzzing engine that receives valid (well formed) data for input into a tested software application. Responsive to receiving the valid data, and in one implementation, the fuzzing engine utilizes a fuzzing data schema that describes characteristics of the well-formed input from a test automation tool to generate corresponding malformed data for input into and fuzzing the tested application. In another application, the fuzzing engine is hard-coded to present malformed data to the tested application in response to receiving particular valid input data. That is, the received valid input data is mapped to corresponding malformed data, or the malformed data is automatically generated from the valid input data via one or more well known data fuzzing algorithms. In one implementation, the malformed data is provided to the tested application via a fuzzing API, respective portions of the fuzzing API are implemented by the fuzzing engine and a test automation tool. In one implementation, the tested application is brought to a particular application state before the systems and methods begin fuzzing the tested application. In another implementation, the malformed data is provided to the tested application via a network proxy or a local filter driver that intercepts about input data being input into the tested application. Once intercepted, the valid input data is fuzzed and forwarded to the tested application to identify any security vulnerabilities.

These and other aspects of the systems and methods for Delivering malformed data for fuzz testing software applications are now described in greater detail

An Exemplary System

Although not required, the systems and methods to deliver malformed data for fuzz testing software applications are described in the general context of computer-program instructions being executed by a computing device such as a personal computer. Program modules generally include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. While the systems and methods are described in the foregoing context, acts and operations described hereinafter may also be implemented in hardware.

FIG. 1shows an exemplary system100to deliver malformed data for fuzz testing software applications, according to one embodiment. In this implementation, system100includes computing device102coupled over communication network104to remote computing device106. Computing device102represents, for example a general purpose computing device, a server, a laptop, a mobile computing device, and/or so on, that accepts information in digital or similar form and manipulates it for a specific result based upon a sequence of instructions. Computing devices102and106include one or more processors coupled to respective tangible computer readable data storage media such as a system memory. System memory includes program data and computer-program modules comprising computer-program instructions for execution by a processor.

For example, computing device102includes processor108coupled to a tangible computer-readable data storage medium such as a system memory110. System memory110includes, for example, volatile random access memory (e.g., RAM) and non-volatile read-only memory (e.g., ROM, flash memory, etc.). Processor108may be a microprocessor, microcomputer, microcontroller, digital signal processor, etc. System memory110includes program modules116. Each program module116is a computer-program application including computer-program instructions executable by processor108. System memory110also includes program data124that is generated and/or used by respective ones of the program modules116.

In this implementation, for example, computing device102program modules112include fuzz-testing (“fuzzing”) engine116, test automation tool118, and “other program modules”120such as an Operating System (OS) to provide a runtime environment, an XML editor, device drivers, etc. Fuzzing engine116generates malformed data122for input into a tested software application124. Fuzzing engine116generates one or more permutations of malformed data122from valid (well-formed) input data126for the tested application. Exemplary aspects of fuzzing data schema132are described in greater detail below in the section titled “Modeling Well-Formed (Valid) Input Data for Software Application”. In another implementation, fuzzing engine116uses known techniques to malformed data122from valid input data126. In the implementation ofFIG. 1, tested software application124is shown on remote computing device106. However, in another implementation, tested software application124is on a same computing device as fuzzing engine116. Such an alternate implementation is described below in the section titled “Proxy”, wherein the proxy is a device driver, or “filter proxy.”

Fuzzing engine116inputs, using one or more of multiple possible data input techniques, the malformed data122into tested application124to fuzz tested application124. These techniques include, for example, delivering malformed data122using a fuzzing Application Program Interface (API)128, delivering malformed data122as a network proxy, delivering malformed data122via a filter interface, and/or so on. Each of these respective techniques to deliver malformed data122to tested application to fuzz the tested application and identify any security vulnerabilities are now described.

An Exemplary Fuzzing API

In one implementation, the fuzzing engine116and test automation tool(s)118(or other applications) expose a respective portion of a fuzzing API128to fuzz a tested application124. The particular implementation of a test automation tool118is arbitrary and that it is a function of the particular implementation of the software application being tested (i.e. tested software application124). In one implementation, test automation tool118performs both functional testing (to assess predetermined application functionality responsive to receipt of valid data inputs) and fuzz testing of tested application124. We now describe an exemplary implementation and use of fuzzing API128.

Referring to TABLE 1, class FuzzingConsumer is implemented by test automation tool118to allow fuzzing engine116to fuzz a tested application124. For purposes of exemplary illustration, interfaces exposed via the Fuzzing Consumer class are shown as fuzzing consumer API134, which is respective portion of fuzzing API128. The particular implementation of class FuzzingConsumer is arbitrary, depending on the particular implementation of how the tested application124obtains data inputs (e.g., via pre-specified data input mechanisms such as an API, a socket, a file, etc.). For instance, if software application124is an SMTP application, fuzzing engine116sends fuzzed data to the SMTP application via a socket. In this particular implementation, and for purposes of exemplary description, class FuzzingConsumer is designed to provide input to the tested application via a socket “s”. The socket structure is well known. For example, in one implementation, the socket is an Internet socket (or commonly, a network socket), representing a communication end-point unique to a machine102or106communicating on an Internet Protocol-based network104, such as the Internet. An Internet socket indicates, for example, one or more of a protocol (TCP, UDP, raw IP, etc.), a local IP address, a local port, a remote IP address, and a remote port.

The FuzzingConsumer.Consume” interface is called by the fuzzing engine116to deliver fuzzed data (a respective portion of malformed data122) to tested application124. The particular implementation of “FuzzingConsumer.Consume” is arbitrary because Consume is designed to work with the particular technique/methodology implemented by the tested application to receive input data. For example, in one implementation, the fuzzed data is sent to tested application124using a socket over network132to the tested application. In another implementation, for example, or application124is local to computing device102, the fuzzed data is passed to tested application124via a call to an exposed API130, via a file, and/or so on. The particular implementation of API130is arbitrary as it is a function of the particular implementation of tested application124.

Referring to TABLE 1, class Fuzzer does this implementation, for example, exposes interfaces Fuzzer.Initialize and Fuzzer.DoFuzzing, both of which are called by a test automation tool118to fuzz tested application124. For purposes of exemplary illustration, interfaces exposed via class Fuzzer are shown as API136, which is respective portion of fuzzing API128. Fuzzer.Initialize initializes parameters to enable fuzzing the tested application124. In this implementation, such parameters include, for example, “Schema”, “TestCase”, and “Consumer.” “Schema” identifies a fuzzing data schema132for initialization. Exemplary aspects of fuzzing data schema132are described in greater detail below in the section titled “Modeling Well-Formed (Valid) Input Data for Software Application”. Interface Fuzzer.Initialize ( . . . ) prepares the specified fuzzing data schema132for fuzzing. Fuzzing Engine would then perform initialization of the engine, such as schema loading and/or schema118compilation.

The “TestCase” parameter indicates a particular predetermined application state of multiple possible application states where fuzzing of the tested application should begin. The particular execution states of an application are arbitrary, being a function of the particular implementation of the application. For example, please consider a typical two state web application, which (1) performs login, returning a session cookie, and (2) requires this cookie to be provided for all further requests. In this example, a first TestCase will indicate a need to fuzz the login request, and a second TestCase will indicate a need to fuzz regular application request, which will indicate a need for fuzzing engine to place a session cookie in the request. In a scenario where application requests in the 2ndstate are to be fuzzed, fuzzing engine116allows test automation to perform processes to bring the tested application to the target state (e.g., test automation logs-in, obtains session cookie, and/or so on). In this example, when the session cookie is present, fuzzing engine116performs fuzzing of application request(s).

The “Consumer” parameter of Fuzzer.Initialize identifies a specific instance of class FuzzingConsumer (described above) that has been instantiated by test automation tool118. Responsive to receiving this parameter, fuzzing engine116initializes the specific instance by keeping the reference to consumer interfaces, so that it can use it later when producing fuzzing output. Fuzzing.DoFuzzing” interface is called by test automation tool118to fuzz input data specified by “Input[ ].” In this implementation, for example, “DoFuzzing” builds fuzzed data and passes it to Consumer.Consume to send the fuzzed input to tested application124.

TABLE 2 shows exemplary functional test automation code before it was modified to utilize fuzzing API128to fuzz a tested application124. This non-modified functional test example is shown to compare and contrast a purely functional test to a functional test that has been modified to implement fuzzing via the fuzzing API, as described below with respect to TABLE 3. The functional test of TABLE 2, as do all functional tests, validates that certain functionality in a tested application works as expected. The tested functionality, as well as the particular implementation of the functional test, is clearly arbitrary because it is a function of the particular implementation/architecture of the tested application.

TABLE 3 shows the same exemplary functional test automation code as TABLE 2, with the exception that the code of TABLE 2 has been modified (modifications are italicized) to utilize the fuzzing API128(a combination of APIs134and136) to fuzz tested application124.

TABLE 3AN EXEMPLARY MODIFIED FUNCTIONAL TEST FOR FUZZINGvoid test (socket s, int param){FuzzingConsumer fc (s);Fuzzer fuzzer = new Fuzzer ( );Fuzzer.Initialize (“c:\temp\schema.fgxml”, “http-request”, fc);char buf [100];sprintf (buf, “Test input %d”, param);fuzzer.DoFuzzing (buf);// Please note that “send” was replaced// with this fuzzing operation.}
Referring to TABLE 3, for purposes of exemplary illustration and description, the tested functionality of this example is to drive the tested application to an application/execution state that is responsive to receiving the indicated input data at the indicated socket (please see the call to “send” in TABLE 2 and FuzzingConsumer.Consume). In this manner, the positive code path(s) used to respond to receipt of valid input data can be fuzzed with corresponding malformed data122. In one implementation, test automation tool118performs both functional testing and fuzz testing.

Proxy

In another implementation, fuzzing engine116is implemented in association with proxy such as a network based proxy or a local filter driver to respectively and transparently intercept network104and/or local communication(s) between test automation tool(s)118and tested application124. For purposes of exemplary illustration, such a proxy is shown as a respective portion of “other program modules”120. In one implementation, the test automation tool performs functional testing to assess predetermined application functionality responsive to receipt of valid data inputs, not fuzz testing. The intercepting proxy redirects the intercepted communication(s) to fuzzing engine116. The fuzzing engine parses the intercepted communication to identify and fuzz at least a subset of the data associated with the intercepted communication(s) to generate fuzzed data (i.e., respective portions of malformed data122). In certain scenarios such as network-based communication, the intercepted communication may be a packet associated with a protocol (e.g., TCP, UDP, DCOM, RPC, etc.). In such scenarios, fuzzing engine116maintains correctness (e.g., header(s), etc.) of the protocol and malforms only data targeted for consumption by tested application124to generate fuzzed packets (please see “other program data”142). The fuzzing engine returns the fuzzed data (possibly representing fuzzed packet(s)) to the proxy, which directly forwards the fuzzed data to the tested application for consumption.

For example, fuzzing engine116parses well formed data received from test automation118. In one implementation, for example, fuzzing engine116attempts to match the parsed data to characteristics in fuzzing data schema132(or a hardwired malformed version) and a current state (test case). If the input was not matched, it is assumed to belong to a different state and is passed as is to the tested application (local in the scenario of a local filter driver proxy, or remote in the case of a network proxy). If the input matches the schema and testcase, fuzzing engine116applies fuzzing transformations and produces fuzzed data, which is then sent to tested application.

FIG. 2shows an exemplary system for using a network proxy to deliver malformed data for fuzzing a software application, according to one embodiment. For purposes of exemplary illustration and discussion, aspects ofFIG. 2are described with respect toFIG. 1. For example, the left-most numeral of a reference number indicates the particular figure where the component was first introduced. In this example, network proxy computing device202(FIG. 1) comprises fuzzing engine116to intercept network communications204from test automation tool118. In this example, the network communications204are initially directed to tested software application124as well-formed data input. In one implementation, test automation tool118is a functional test computer-program application, as compared to a fuzzing application. The fuzzing engine116intercepts the network communications204, malforms the associated well-formed data, and forwards the malformed data to the same respective input destinations (e.g., socket(s), etc.) as originally indicated by respective ones of the network communications204. In one implementation, the well-formed data is fuzzed using a fuzzing data schema132. In another implementation, the well-formed data is fuzzed via one or more well-known fuzzing techniques (e.g., techniques based on data type, etc.).

Modeling Well-Formed (Valid) Input Data for a Software Application

In one implementation, a software developer or other user manually defines fuzzing data schema132. For example, a user interfaces with an Extensible Markup Language (XML) editing application to generate fuzzing data schema132. Although fuzzing data schema132is shown as local to computing device102, in another implementation, fuzzing data schema132is remote from computing device102(e.g., in a database coupled to computing device102over a network104, etc.). Fuzzing data schema132describes/models characteristics (e.g., data types, attributes, relationships, input sequences, etc.) of well-formed valid input data (e.g., input data, message protocol formats, etc.) for a particular software application (e.g., tested application124). This data modeling does not directly provide specific instances of well-formed data for the software application, but rather describes attributes, characteristics, etc. that a specific instance of well-formed data would have. The software application can be any arbitrary application. For instance, valid input data to a web browser software application124includes, for example, HTTP protocol response message to present HTML web pages. In another example, valid input data to a SMTP server software application124include data to present SMTP-based messages. In either of these exemplary scenarios, the user models corresponding protocols (e.g., HTTP, HTML, SMTP, and/or so on), including each specific form of the protocol. Examples of valid input data modeling for fuzzing data schema132are presented below.

To model valid (well-formed) input data for software application124, a user decomposes the input data into atomic groups of groups of elements or primitive elements (strings, numbers, etc.). For each element, the fuzzing data schema132indicates data type, valid values or relationships (e.g., attributes describing legitimate variations of the element such as data length, valid ranges, minimum/maximum values, and/or so on). Such relationships/attributes/valid formats indicate appropriate value(s) of an element for well-formed (i.e., expected) input into the software application. For variable length fields, fuzzing data schema132indicates how to detect field termination (e.g., by whitespace or carriage return character, etc.). TABLES 4 and 5 respectively show an exemplary set of elements (data fields and attributes) and groups of elements or groups (e.g., a group of groups) to model well-formed input data for software application124. Although a certain number of elements and groups are described with respect TABLES 4 and 5, it can be appreciated that system100can use other elements and groups to model well-formed input data for software application124.

TABLE 4EXEMPLARY ELEMENTS TO DESCRIBE WELL-FORMED INPUTNamePurposeCharacterString with ASCII or Unicode charactersStringof variable length. In thisimplementation, length is fixed ordetermined by specified terminator. Inone implementation, a valid character setis specified.NumericNumber encoded as string. Can beStringsigned or unsigned. Can be integer orfloating type. Valid range(s) and/orfloating point precision is specified.IntegerNumber binary encoded. Can be signedor unsigned. Valid ranges are specified.ByteStream of binary bytes. Length is fixedArrayor determined by specified terminator.Bit ArrayAn array data structure which compactlystores individual bits (0 or 1)

Referring to TABLE 4, and in this implementation, respective ones of well-formed data elements for input into software application124are modeled in fuzzing data schema132, for example, as a corresponding character string, numeric string, integer, byte array, or bit array. A character string is a string of ASCII or Unicode characters of variable length. String length is fixed or determined by a specified terminator. In one implementation, a valid character set is specified. A numeric string is a number encoded as a string. Such a number (e.g., integer, binary coded number, floating point) is signed or unsigned. In one implementation, valid range relationships and/or precision attribute(s) is/are specified for a number. A byte array element is a stream of bytes. The length of the byte array is fixed or determined by a specified terminator. A bit array element is an array data structure which compactly stores individual bits (0 or 1).

TABLE 5EXEMPLARY GROUPS TO DESCRIBE WELL-FORMED INPUTNamePurposeSequentialMultiple elements or groups in a specifiedorder are contained in a sequential group (agroup can encapsulate other groups).Single-Only one element or group out of specifiedChoicelist of elements or groups is contained in asingle-choice groupMulti-Multiple elements or groups in any order areChoicecontained in a multi-choice groupBit ArrayA list of binary bits of a certain length isGroupcontained in a bit array group

Referring to TABLE 5, and in this implementation, groups in fuzzing data schema132include, for example, one or more sequential groups, single-choice groups, multi-choice groups, and bit array groups. A sequential group includes multiple elements or groups of element(s) in a specified order. For example, if software application124expects to receive element (field) “A”, field “B”, and field “C”, in the specified order, schema would contain a sequential group with data fields (elements) A, B and C. A single-choice group represents only one element or group out of possible options. A multi-choice group represents multiple elements or groups in any order contained in the group. A bit array group is a list of bits contained in the group.

For example, and in one implementation, fuzzing data schema132describes a simple HTTP Message in XML as follows:

Valid Input Data Generation and Mutation to Generate Malformed Input

In one implementation, fuzzing engine116parses fuzzing data schema132to create valid input data126. Valid input data126represents data that conforms to respective elements in fuzzing data schema132. Since fuzzing application models well-formed data for input into software application124, valid input data126represents valid data for input into software application, i.e., data that software application124was designed to consume or process.

In one implementation, for example, fuzzing engine116randomly generates valid input data126by iterating through each group and element combination in fuzzing data schema132, generating respective portions of valid input data according to the characteristics of the specific group type (e.g., sequential, single-choice, multiple-choice, etc) and element type (character string, numeric string, integer, length, valid range, etc.). For example, to generate valid input data126associated with a single choice group, one of the specified element(s) is randomly selected and created. In another example, fuzzing engine116generates a string element by iterating between zero (0) and a random length, within an allowed specified maximum indicated by element attributes/properties (e.g., valid range, minimum/maximum values, byte array length, etc.). For every character, a random character within an allowed specified set is generated.

After creating valid input data126, and in one implementation, fuzzing engine116parses and mutates/changes valid input data126to generate malformed data122(properly formed invalid data) for input to and fuzz-testing of software application124. To this end, fuzzing engine116parses valid input data126to generate a tree of groups and elements138and corresponding attributes (valid ranges, characteristics, etc) to representing valid input data126. Tree138isolates valid element data associated with respective individual elements of valid data126so that malformed data122can be generated from respective ones of the isolated elements.

For example an HTTP Message that would correspond to above schema would be:

In this example, “GET” string corresponds to “Method” token, “HeaderA” and “HeaderB” correspond to “Header” sequential group and “Body” corresponds to “body” ByteArray.

Next, and in one implementation, fuzzing engine116applies one or more known fuzzing algorithms to at least a subset of the data elements in tree138to corrupt the data elements according to well-known data type based vulnerability patterns. For instance, one exemplary fuzzing algorithm inserts null values into string element(s). Another exemplary fuzzing algorithm, for example, may sets integer value(s) to a maximum value+1 in a specified allowable range, and/or so on. Fuzzing engine116further serializes the resulting mutated data tree (i.e., a data tree with fuzzed/corrupted data inputs), resulting in fuzzed data buffer Q126(or mutation template). Serialization is a common computer term for converting a data structure comprised of a few elements into a data buffer. For purposes of exemplary description, a mutation template is a sample of a legitimate data.

Exemplary Data Fuzzing Result Presentation

Responsive to receiving a piece of malformed data122, if software application124crashes (or otherwise performs contrary to target design), the fuzzing operations have identified a security vulnerability in a code portion of software application124corresponding to the received piece of malformed data122. In this scenario, an end-user of system100is put on notice by the crashing or contrary operations that the software application124has one or more corresponding code paths are vulnerable with respect to security. In another implementation, such crashing and/or contrary operations cause system100to automatically notify a user (e.g., via a display device) of information associated with the identified security vulnerability. Otherwise, if no crash (or other unusual behavior) of software application124occurs, no security vulnerability was identified in the corresponding portion of code (i.e., the code portion is validated).

Exemplary Procedures

FIG. 3shows an exemplary procedure300to generate and deliver malformed data for software application fuzzing, according to one embodiment. For purposes of exemplary illustration and discussion, aspects ofFIG. 3are described with respect toFIG. 1. For example, the left-most numeral of a reference number indicates the particular figure where the component was first introduced. Referring toFIG. 3, operations at block302receive valid well-formed data126from a test automation tool118. Operations of block304change the received data126to generate corresponding malformed data122based on characteristics of the received data. Operations at block306input the malformed data122into an application124to fuzz one or more code paths designed to process the valid well-formed a data. Operations at block308, responsive to the application124crashing or otherwise performing contrary to expectations responsive to the operations of block306, notify a user that the one or more code paths have security vulnerability.

FIG. 4shows an exemplary procedure for use of an application programming interface to generate and deliver malformed data for software application fuzzing, according to one embodiment. For purposes of exemplary illustration and discussion, aspects ofFIG. 4are described with respect toFIG. 1. For example, the left-most numeral of a reference number indicates the particular figure where the component was first introduced.

Referring toFIG. 4, operations at block402issue, by a functional test module (e.g., a test automation tool118), and initialize request to a fuzzing engine. The request is to initialize a set of data in preparation for fuzzing an application124. In one implementation, the request is a Fuzzer.Initialize request of a fuzzing API128. Operations of block404communicate a fuzzing request to the fuzzing engine116to direct the fuzzing engine to generate and communicate to the application124a set of malformed data122. The set of malformed data122is associated with a set of well-formed data126. In one implementation, the fuzzing request is a Fuzzer.DoFuzzing request of the fuzzing API128. Operations at block406process, by the application being tested, the malformed data122to determine any security vulnerabilities in one or more code paths. The one or more code paths are designed to properly process the well-formed data from which the malformed data was generated. Operations at block408notify an end-user of any security vulnerabilities identified responsive to fuzzing the one or more code paths with the malformed data.

FIG. 5shows an exemplary procedure for a network proxy to generate and deliver malformed data for software application fuzzing, according to one embodiment. For purposes of exemplary illustration and discussion, aspects ofFIG. 5are described with respect toFIG. 1. As in the above figures, the left-most numeral of a reference number indicates the particular figure where the component was first introduced. Referring toFIG. 5, operations at block502intercept a message communicated over a network104to a software application124for testing. Operations of block504parse the message to identify a set of valid input data126for input to the software application being tested. Operations of block506generate a set of malformed data122from characteristics of the valid input data. In one implementation, such characteristics are specified by a fuzzing data schema132. In another implementation, such characteristics are specified by well-known fuzzing algorithms that fuzz data based on data type, etc. Operations of block508, communicate the malformed data to the software application being tested for processing and fuzzing of the software application. These operations assist a user in identifying any security vulnerabilities associated with fuzzed code paths of the software application.

Alternate Embodiments

Although system100ofFIG. 1has been described as using valid input data126(generated from fuzzing data schema132) merely to generate structure and content associated with malformed data122, in another implementation valid input data126is used for additional purposes. For example, in one implementation, valid input data126is utilized to perform functional testing and/or results of software application124(this is as compared to utilizing malformed data122to identify code portions of software application124with security vulnerability). For purposes of exemplary illustration, testing tool118also inputs data from valid input data126into software application124to test operations of software application124. For example, in one embodiment, valid input data126specifies content of one or more messages for communication to the software application124according to a specific protocol described by the fuzzing data schema132. In this embodiment, the testing tool communicates at least a subset of the messages to the software application124to validate whether the software application properly processes the received messages. This is only one arbitrary example of using a particular exemplary aspect of valid input data126to test proper functioning of software application124. There are many different scenarios where different types of valid input data126are used to test operations of software application116.

Conclusion

Although the above sections describe delivering malformed data for fuzz testing software applications in language specific to structural features and/or methodological operations or actions, the implementations defined in the appended claims are not necessarily limited to the specific features or actions described. Rather, the specific features and operations to deliver malformed data for software application and fuzzing are disclosed as exemplary forms of implementing the claimed subject matter.