Fuzzing Overview

Fuzzing in Dochia provides continuous, randomized testing using mutators rather than pre-defined playbooks. This approach allows for exploratory testing and discovery of unexpected vulnerabilities through random mutations of request data.

Unlike structured playbooks that test specific scenarios, fuzzing applies 28 different mutators randomly to generate unpredictable test cases, making it ideal for discovering edge cases and unknown vulnerabilities.

Fuzzing vs Playbooks

Aspect	Playbooks	Fuzzing
Approach	Structured, predefined test cases	Random, continuous mutations
Coverage	Comprehensive, systematic	Exploratory, unpredictable
Use Case	Validation, compliance testing	Vulnerability discovery
Duration	Fixed test suite	Continuous until stopped
Targeting	All endpoints and methods	Single endpoint/method

Available Mutators

The fuzzing engine uses 28 mutators that can be grouped into the following categories:

String and Text Mutations

• BigListOfNaughtyStringsMutator: Replace fields with known problematic strings
• RandomAlphanumericStringMutator: Replace fields with random alphanumeric characters
• RandomStringMutator: Replace fields with random Unicode strings
• NullStringMutator: Replace fields with null values
• RandomLanguageIdentifiersMutator: Replace fields with programming language keywords

Unicode and Special Characters

• RandomAbugidasMutator: Inject random abugidas characters
• RandomControlCharsMutator: Replace fields with random control characters
• RandomControlCharsInFieldKeysMutator: Insert random control chars in field keys
• RandomWhitespaceCharsMutator: Replace fields with random whitespace characters
• RandomWhitespacesInFieldKeysMutator: Insert random whitespaces in field keys
• RandomZalgoTextMutator: Replace fields with random zalgo text
• RandomMultiCodepointEmojisMutator: Replace fields with multi-codepoint emojis
• RandomSingleCodepointEmojisMutator: Replace fields with single-codepoint emojis

Numeric Mutations

• RandomNumberMutator: Replace fields with random long numbers
• RandomLargeIntegersMutator: Replace fields with random large integers
• RandomLargeDecimalsMutator: Replace fields with random large decimals
• RandomMaxValuesMutator: Replace fields with maximum values for numeric types
• RandomMinValuesMutator: Replace fields with minimum values for numeric types

Case Expansion Testing

• LowercaseExpandingBytesMutator: Replace fields with strings that expand bytes when lowercased
• LowercaseExpandingLengthMutator: Replace fields with strings that expand length when lowercased
• UppercaseExpandingBytesMutator: Replace fields with strings that expand bytes when uppercased
• UppercaseExpandingLengthMutator: Replace fields with strings that expand length when uppercased

Structure and Format Mutations

• RandomJsonMutator: Replace body with random invalid JSON
• RandomPayloadSizeMutator: Replace payload with substring of random length
• RemoveFieldMutator: Remove fields from the request body

Header Mutations

• RandomAcceptHeaderMutator: Replace Accept header with random unsupported media types
• RandomContentTypeHeaderMutator: Replace Content-Type header with random unsupported media types
• RandomTransferEncodingHeaderMutator: Replace Transfer-Encoding header with random values

How to Use Fuzzing

⚠️ REQUIRED ARGUMENTS: The dochia fuzz command requires at least one stop condition (--stop-XX) and at least one match condition (--match-XX) to be specified. Fuzzing cannot run without these parameters.

Basic Fuzzing

# Basic fuzzing of a POST endpoint (with required stop and match conditions)
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --stop-after-time-in-sec 300 \
  --match-response-codes 500

# Fuzzing with authentication
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  -H "Authorization=Bearer $TOKEN" \
  --stop-after-errors 10 \
  --match-input

Time-Based Fuzzing

# Run fuzzing for 5 minutes
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --stop-after-time-in-sec 300 \
  --match-response-codes 500

# Run fuzzing for 1 hour
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --stop-after-time-in-sec 3600 \
  --match-input

Error-Based Stopping

# Stop after finding 10 errors
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --stop-after-errors 10 \
  --match-response-codes 500

# Stop after 1000 mutations
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --stop-after-mutations 1000 \
  --match-input

Advanced Matching

# Match specific response codes as errors
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --match-response-codes 500,502,503 \
  --stop-after-errors 5

# Match responses containing input reflection
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --match-input \
  --stop-after-time-in-sec 600

# Match specific response patterns
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --match-response-regex "error|exception|stack" \
  --stop-after-mutations 500

Custom Mutators

# Use custom mutators from a folder
dochia fuzz -c api.yml -s https://api.example.com \
  -p /users -X POST \
  --mutators ./custom-mutators/ \
  --stop-after-time-in-sec 1800 \
  --match-response-codes 500

Fuzzing Strategies

Discovery Fuzzing

Use fuzzing to discover unknown vulnerabilities and edge cases:

# Long-running discovery fuzzing
dochia fuzz -c api.yml -s https://api.example.com \
  -p /api/data -X POST \
  --stop-after-time-in-sec 7200 \
  --match-response-codes 500 \
  --match-input

Targeted Vulnerability Testing

Focus on specific vulnerability types:

# Test for injection vulnerabilities
dochia fuzz -c api.yml -s https://api.example.com \
  -p /search -X POST \
  --match-response-regex "sql|query|database|syntax" \
  --stop-after-errors 5

Performance Impact Testing

Test for performance degradation:

# Test for slow responses
dochia fuzz -c api.yml -s https://api.example.com \
  -p /compute -X POST \
  --max-response-time 5000 \
  --stop-after-mutations 500 \
  --match-response-codes 500

Match Options

Fuzzing provides powerful matching capabilities to identify interesting responses:

Response Code Matching

• --match-response-codes: Match specific HTTP response codes as errors
• Example: --mc 500,502,503 matches server errors

Content Matching

• --match-input: Flag responses that reflect the fuzzed input
• --match-response-regex: Match responses against regex patterns
• --match-response-size: Match specific response sizes
• --match-response-lines: Match specific line counts
• --match-response-words: Match specific word counts

Stop Conditions

• --stop-after-errors: Stop after finding N errors
• --stop-after-mutations: Stop after N test cases
• --stop-after-time-in-sec: Stop after N seconds

Best Practices

1. Start with Short Sessions

# Begin with short fuzzing sessions
dochia fuzz -c api.yml -s https://api.example.com \
  -p /endpoint -X POST --st 60

2. Use Appropriate Match Criteria

# Match server errors and input reflection
dochia fuzz -c api.yml -s https://api.example.com \
  -p /endpoint -X POST \
  --mc 500 --match-input

3. Monitor Resource Usage

# Limit request rate for production testing
dochia fuzz -c api.yml -s https://api.example.com \
  -p /endpoint -X POST \
  --max-requests-per-minute 60

4. Use Error Keywords

# Detect error information leaks
dochia fuzz -c api.yml -s https://api.example.com \
  -p /endpoint -X POST \
  --error-keywords error-keywords.properties

See Also

• Body Playbooks - Structured body testing
• Fields Playbooks - Individual field validation
• Headers Playbooks - Header manipulation testing
• Playbooks Overview - General introduction to playbook types

Detailed Guide to Mutators

String and Text Mutations

BigListOfNaughtyStringsMutator

• Description: Replaces fields with known problematic strings from security research
• Use Case: Tests against common injection patterns and edge cases
• Example: Replaces field with strings like '; DROP TABLE users; --

RandomLanguageIdentifiersMutator

• Description: Replaces fields with programming language keywords
• Use Case: Tests for code injection and language-specific vulnerabilities
• Example: Replaces field with SELECT, eval, exec, import

Unicode and Special Characters

RandomZalgoTextMutator

• Description: Replaces fields with zalgo text (combining characters)
• Use Case: Tests Unicode handling and rendering safety
• Example: T̸̰̈́h̷̰̾i̵̱̍s̶̰̈́ ̷̰̾i̵̱̍s̶̰̈́ ̷̰̾ẕ̵̍ä̶̰́l̷̰̾g̵̱̍ö̶̰́

RandomControlCharsMutator

• Description: Replaces fields with random control characters
• Use Case: Tests parsing robustness and security filtering
• Example: Fields containing \x00, \x1F, \x7F

Numeric Mutations

RandomMaxValuesMutator

• Description: Replaces numeric fields with maximum values for their data types
• Use Case: Tests integer overflow and boundary conditions
• Example: 2147483647 for int, 9223372036854775807 for long

RandomLargeDecimalsMutator

• Description: Replaces fields with very large decimal numbers
• Use Case: Tests floating-point handling and precision limits
• Example: 1.7976931348623157E+308

Structure and Format Mutations

RandomJsonMutator

• Description: Replaces request body with malformed JSON
• Use Case: Tests JSON parser robustness
• Example: {"key": "value" malformed}

RemoveFieldMutator

• Description: Randomly removes fields from request payloads
• Use Case: Tests required field validation
• Example: Removes email field from user registration request