Response Partitions

In software testing there is the concept of Equivalence Partitioning. Response Partitions are Fuzzing Hero's approach at helping customers determine the effectiveness and quality of a scan by helping map outcome behavior.

Equivalence Partitioning

Conceptually if an application's endpoint can respond 3 different ways, an effective test of that endpoint would be to generate inputs that meet the conditions so that all code paths were reached.

Take a sample Flask route like the following:

@app.get("/validate/<int:value>")
def validate(value):
    if value <= 0:
        return {"message": "must be greater than 0"}, 400

    if value <= 5:
        return {"message": "valid"}, 200

    return {"message": "invalid input"}, 403

The endpoint takes a single integer value as input value. There are 3 branches:

• value <= 0 (e.g. -1, 0, -5000, etc.)
• 0 < value <= 5 (e.g. 1, 2, 3, 4, 5, etc.)
• value > 5 (e.g. 6, 10, 100, 9999, etc.)

Proper coverage would attempt at least one input that meets each condition (i.e. one input <= 0, one input 0 < value <= 5, and one input > 5).

Fuzzing Hero's Approach

From a dynamic perspective, Fuzzing Hero doesn't have access to the target's source code. However, we do have visibility into the responses from the application. We help analyze fuzzing results by listing the unique responses and sharing a subset of the input that caused that type of response.

Working backwards, Fuzzing Hero can help you determine things like:

• Our unit tests were missing coverage for edge cases
• We thought input X would respond with Y, but it responded with Z

If you have an endpoint that reflects user input (like a search bar), you'll likely see a lot of variations of the same response. We attempt to normalize response patterns so that partitions will show truly unique behavior.

This powerful feature saves you time from scrolling through tables of information looking for outliers. It enables you to quickly identify unexpected behavior and focus on what matters.