Engineering Notes: WSHawk

These notes distinguish implemented behavior from benchmark evidence. WSHawk’s checked-in labs validate known controls; they do not establish universal performance or detection rates for arbitrary targets.

Note 1: Browser-Assisted XSS Evidence

A reflected payload is not proof that JavaScript executed. WSHawk can replay suspected content in an isolated Chromium context and observe execution beacons and relevant DOM changes.

This is a confirmation layer, not a guarantee. Content Security Policy, authentication state, application routing, timing, and differences between the test DOM and the production page can change the result. The operator should retain the original response and the browser evidence together.

Note 2: Smart Payload Evolution

The Smart Payload Engine uses message context, response classification, mutation, and crossover to explore payload variants. Fitness signals can include blocking, reflections, errors, and timing changes.

A higher fitness score means that a candidate produced an interesting target response; it does not by itself prove exploitation. Protocol-specific evidence and manual review remain part of the reporting workflow.

Note 3: Blind Vulnerabilities and OAST

SSRF, XXE, and command-injection paths may produce no useful inline response. WSHawk correlates unique callback identifiers with outbound DNS or HTTP interactions through a configured OAST provider.

OAST confirmation depends on a controlled callback service, correct correlation, and awareness of background network noise. Callback tokens and logs must be treated as sensitive engagement data.

Note 4: Asynchronous WebSocket Evaluation

WebSocket applications can emit responses long after a frame is sent. WSHawk separates sending, receiving, correlation, timeout, and cancellation so delayed messages can be associated with the relevant test window.

Correlation remains application-aware work. Broadcast traffic, server heartbeats, and multiplexed subscriptions can look like payload responses unless the operator supplies a useful message template and enough context.

Note 5: Cross-Site WebSocket Hijacking

CSWSH testing changes the WebSocket Origin while preserving the authentication context needed for an authorized assessment. A successful handshake with an untrusted origin is evidence worth investigating, but exploitability also depends on cookie policy, browser behavior, and the actions exposed by the channel.

The defensive validator complements the offensive probe by checking Origin handling and TLS posture without assuming that one status code proves the complete impact.

Note 6: Two Desktop Architectures

WSHawk v4.0.4 publishes two separate desktop editions:

• the classic Electron application backed by the Python runtime;
• the Electron + Go application backed by a private Go worker over versioned local JSON-RPC.

The Go-backed edition is not a distributed Redis scanning mesh. Its worker, project data, and IPC boundary are local to the packaged desktop application.

Note 7: Identity-Aware Authorization Testing

Authorization testing applies anonymous and recorded identities to the same HTTP, GraphQL, or WebSocket operation. Matrices, object-ID mutation, semantic comparison, and policy-aware findings help identify horizontal and vertical access-control differences.

An observed difference is not automatically a vulnerability. The endpoint’s intended policy, object ownership, tenant boundary, and identity freshness determine the result. Findings therefore preserve aliases, sanitized requests, statuses, bodies or hashes, and replay context.

Note 8: Project Storage and Evidence Protection

Project-backed storage keeps targets, identities, HTTP flows, WebSocket frames, protocol maps, evidence, and findings available for replay and reporting. The Electron + Go edition adds encrypted project content, redaction, retention controls, and hash-only evidence modes.

Storage design reduces renderer memory pressure and improves reproducibility, but the project database still contains sensitive assessment material. Operators should use access controls, backups, and retention policies appropriate to the engagement.

Note 9: Bounded Web Testing

HTTP replay, crawling, directory discovery, header analysis, CORS checks, race testing, and mutation can generate substantial traffic. WSHawk exposes cancellation, timeouts, rate limits, and bounded queues so the operator can keep a test inside the authorized scope.

The regression suite intentionally avoids denial-of-service and maximum-throughput testing. Production rate limits and state-changing endpoints require explicit planning.

Note 10: Reporting and Benchmark Integrity

WSHawk exports machine-readable and human-readable evidence, including JSON, HTML, CSV, and SARIF where supported by the selected edition. Redaction and integrity metadata help preserve a defensible record, but exported reports still need scope and severity review.

The main benchmark contains 26 paired HTTP/WebSocket cases. The Electron + Go authorization lab contains 34 HTTP, GraphQL, and WebSocket scenarios. These are reproducible functional controls, not universal WAF-bypass, false-positive, or throughput claims.

Reproducibility

python -m benchmarks.run --iterations 3 --warmup 1

cd electron-desktop
npm run test:authorization-benchmark

Run only against systems you own or are explicitly authorized to assess.