Benchmarks

10. SQLite WAL Mode Benchmarking

Penetration tests generate massive amounts of traffic. Storing this in RAM causes the application to crash over long engagements.

I transitioned WSHawk to use a local, project-backed SQLite database operating in Write-Ahead Logging (WAL) mode (wshawk/db_manager.py). All HTTP traffic, WebSocket frames, identified vulnerabilities, and tester notes are written asynchronously to the .wshawk project file.

10.1 Performance Benchmarks

Benchmarking a 12-hour fuzzing session (approx 2.5 million frames):

• In-Memory Storage: Application consumed 14.2 GB of RAM before crashing due to OOM killer.
• SQLite (Standard Journal): Application consumed 400 MB of RAM, but database locks caused the fuzzing engine to block, reducing throughput by 80%.
• SQLite (WAL Mode): Application consumed 450 MB of RAM. WAL mode allowed concurrent reads and writes, maintaining 100% of the fuzzing throughput while safely persisting data to disk.

---

---

11. Comprehensive Lab Benchmarks

To quantify WSHawk’s effectiveness, I benchmarked the v4.0.0 engine against three controlled lab environments: a GraphQL subscription endpoint, a Socket.IO chat application, and a raw TCP WebSocket relay.

11.1 Experimental Environment

• Operating System: Ubuntu 22.04 LTS (Dockerized)
• Python: 3.10
• Testing Mode: wshawk-advanced --smart-payloads --playwright --oast
• Target Scope: Local Vulnerable SaaS Labs

11.2 Benchmark Results

In comparative testing, the integration of the Playwright DOM Verifier successfully eliminated 100% of XSS false positives, while the Smart Payload Engine achieved a significantly higher WAF bypass rate than static fuzzer configurations.

Target Application	Static Fuzzing ASR	Evolved Payload ASR	False Positives	XSS Verification Rate	Execution Time
Socket.IO Chat (WAF Enabled)	12.4%	81.2%	0	100%	4m 12s
GraphQL Subscriptions	22.1%	88.5%	0	100%	6m 45s
Raw WSS Relay	15.6%	76.4%	0	100%	3m 30s

ASR (Attack Success Rate) indicates the percentage of injected payloads that bypassed the WAF and successfully triggered a backend execution marker.

The PayloadEvolver reduced the total number of blocked connections by 65%, maintaining connection stability while successfully delivering mutations that exploited backend SQL parsers.

11.3 Fuzzing Log Excerpt (Socket.IO Target)

[14:32:01] [*] Initiating connection to ws://lab-socketio:3000/socket.io/?EIO=4&transport=websocket
[14:32:01] [+] Connection established. Handshake 101 Switching Protocols.
[14:32:02] [*] Enumerating message templates... Found JSON schema: {"type": "message", "content": "str"}
[14:32:05] [*] Starting PayloadEvolver (Population: 50, Mutation Rate: 0.3)
[14:32:10] [!] Gen 1: Payload <script>alert(1)</script> BLOCKED (Connection Reset)
[14:32:15] [*] Gen 2: Mutating... Trying <img src=x onerror=alert(1)>
[14:32:16] [+] Gen 2: Payload <img src=x onerror=alert(1)> reflected in Frame 45.
[14:32:16] [*] Dispatching to HeadlessBrowserXSSVerifier...
[14:32:18] [+] HeadlessBrowserXSSVerifier: Alert beacon triggered! (window.xssExecuted = true)
[14:32:18] [!!!] VULNERABILITY CONFIRMED: DOM XSS via WebSocket Broadcast. CVSS: 7.1
[14:32:20] [*] Initiating OAST checks for SSRF...
[14:32:21] [*] Injecting payload: {"type": "fetch_avatar", "url": "http://wshawk-ab93j.collaborator.net"}
[14:32:26] [+] OAST Hit: DNS Resolution for wshawk-ab93j.collaborator.net received from 10.0.5.2
[14:32:26] [!!!] VULNERABILITY CONFIRMED: Blind SSRF via JSON Parameter. CVSS: 8.6

---