Fuzzing

Article 2: Stateful WebSocket Vulnerability Detection Algorithms

Source File: wshawk/scanner_v2.py

2.1 The Asynchronous Problem in Protocol Fuzzing

HTTP is inherently stateless and synchronous: Request A yields Response A. Vulnerability scanners map findings by inspecting Response A. If a payload causes a SQL error, that error is returned immediately in the HTTP response body.

WebSockets are full-duplex and asynchronous. The client sends Payload A in Frame 1. The server might immediately respond with a heartbeat ping in Frame 2, broadcast a chat message in Frame 3, and finally return the database error caused by Payload A in Frame 4. A synchronous scanner reading Frame 2 would conclude the payload failed and move on to the next test, completely missing the critical vulnerability exposed in Frame 4.

2.2 Decoupling Send and Receive Loops

In scanner_v2.py, WSHawk solves this synchronization problem by abandoning the standard request-response loop, relying instead on Python’s asyncio event loop.

1. The Send Task: A dedicated coroutine injects payloads into the socket at high speed. It records the exact timestamp, the payload content, and the mutation ID into a sliding window memory structure called the Flight Deck.

2. The Receive Task: A separate coroutine continuously listens to the socket. It parses every incoming frame and runs heuristic regex pattern matching (e.g., searching for SQL syntax errors like SQL syntax or ORA-01756, or XSS reflection markers).

2.3 Correlation Logic and Heuristics

When an error is detected in an incoming frame, the engine scans the sliding window of recently sent payloads on the Flight Deck. It correlates the error to the payload injected within the appropriate timing window.

async def receive_task(self):
    async for message in self.websocket:

---

## Article 5: The WSHawk OAST Callback and Blind Vulnerability Model

*Source File:* `wshawk/oast_provider.py`  

### 5.1 Blind Vulnerabilities in WebSockets
Some of the most critical vulnerabilities—like Server-Side Request Forgery (SSRF), XML External Entity (XXE) injection, and blind command injection—do not return output to the client. 

A payload exploiting a backend webhook processor might succeed perfectly, but the WebSocket frame returned to the WSHawk client merely says `{"status": "processing"}`. Without output reflection, these vulnerabilities are invisible to standard heuristic scanners.

### 5.2 Out-Of-Band Security Testing (OAST)
To detect these flaws, WSHawk integrates an Out-Of-Band (OAST) callback provider mechanism.

1.  **Payload Generation:** The engine generates unique correlation IDs. Instead of injecting a standard payload like `http://localhost`, it injects a unique, tracked domain like `http://wshawk-9f8a2c.collaborator-server.net`.
2.  **Execution:** The payload is sent over the WebSocket. The backend server parses the payload and, if vulnerable to SSRF, performs a DNS lookup or HTTP GET request to the unique domain to fetch the resource.
3.  **Polling and Correlation:** Concurrently, WSHawk polls the OAST provider's API. If the provider logs a DNS or HTTP hit for `wshawk-9f8a2c`, WSHawk correlates that exact ID back to the specific WebSocket payload and timestamp from the Flight Deck. 

```python