V2 Crawlers: Configurable Timeout + Command-Line Execution

[TheAuditorTool]

V2 Crawlers: Configurable Timeout + Command-Line Execution

Closes #3 (Add Timeout to Crawlers)
Closes #1 (Add new command line crawler and verification crawler)

---

Overview

This adds three new Java files alongside the existing crawlers. Nothing existing is changed — the current run-crawler and run-verification-crawler Maven goals continue to work exactly as before. The new functionality is available through separate -v2 goals when you're ready to use it.

What's New

Configurable Timeout (Issue #3)

The current crawlers have a hardcoded 15-second timeout. If a test case takes longer (common on slower machines), the request is dropped.

The v2 crawlers add a -T flag that lets you set the timeout yourself:

Usage	What Happens
No -T flag (the default)	No timeout at all — the crawler waits as long as the test case needs
-T 300	Each request gets up to 5 minutes before it's dropped
-T 60	Each request gets up to 1 minute

When a request does time out, the crawler logs it and moves on to the next test case, just as Jonathon described in the issue.

Command-Line Test Case Execution (Issue #1)

The existing crawlers work by sending HTTP requests to web endpoints. The v2 crawlers can also run test cases as command-line programs — useful for benchmarking non-web applications like Python scripts or CLI tools.

To use this, test cases in the XML file use tcType="CLI" instead of SERVLET, SPRINGWS, or JERSEYWS:

<benchmarkTest tcType="CLI" tcName="PythonTest00001"
    tcCommand="python3" tcCommandArgs="test001.py"
    tcCategory="sqli" tcVulnerable="true"
    tcAttackSuccess="SQL injection detected" ...>
    <formparam name="input" value="' OR 1=1 --" safeValue="hello"/>
</benchmarkTest>

The crawler runs the command as a subprocess, captures its output, and uses the same attack/safe verification logic that the HTTP crawler uses. The formparam elements still switch between attack and safe values — they're passed to the command as --name value arguments.

New Files

All three are in plugin/src/main/java/org/owasp/benchmarkutils/tools/:

File	What It Does
CommandLineTestCaseRequest.java	Represents a CLI test case. Extends AbstractTestCaseRequest so it fits into the existing test suite loading and sorting infrastructure.
BenchmarkCrawler_newv2.java	The basic crawler with timeout support and CLI execution. Extends BenchmarkCrawler. Maven goal: run-crawler-v2.
BenchmarkCrawlerVerification_newv2.java	The verification crawler — sends both attack and safe requests, checks results. Extends BenchmarkCrawler_newv2. Maven goal: run-verification-crawler-v2.

How to Try It

Once installed (mvn install), you can use the new goals in place of the existing ones:

# Basic crawl, no timeout (same behavior as before, minus the 15s cap)
mvn org.owasp:benchmarkutils-maven-plugin:run-crawler-v2 \
    -DcrawlerFile=data/benchmark-crawler-http.xml

# Basic crawl with a 5-minute timeout per request
mvn org.owasp:benchmarkutils-maven-plugin:run-crawler-v2 \
    -DcrawlerFile=data/benchmark-crawler-http.xml -T 300

# Verification crawl with timeout
mvn org.owasp:benchmarkutils-maven-plugin:run-verification-crawler-v2 \
    -DcrawlerFile=data/benchmark-attack-http.xml -T 300

All existing flags (-f, -n, -t) still work. The -T flag is the only addition.

What's Not Changed

• BenchmarkCrawler.java — untouched
• BenchmarkCrawlerVerification.java — untouched
• AbstractTestCaseRequest.java — untouched
• All other existing files — untouched
• Existing XML test suite files — fully compatible with the v2 crawlers

Design Notes

• The v2 crawlers separate connect timeout (always 30 seconds) from response timeout (the -T flag). This means a server that's down still fails fast, while a slow response can take as long as needed.
• CLI test cases reuse the existing ResponseInfo class: stdout goes into responseString, exit code goes into statusCode, and elapsed wall-clock time goes into timeInSeconds.
• The verification crawler uses RegressionTesting.verifyResponse() for CLI test cases. This is the same string-matching logic used for HTTP — checking whether the attack success indicator appears in the output.