Target: https://jawsdemo.northeurope.cloudapp.azure.com/
Date: 2026-04-07
Scope: Web application
Application: JaWS Demo v0.0.8 (jaws@v0.301.0) — Go-based real-time collaborative UI framework
Source: https://github.com/linkdata/jaws (reviewed at HEAD)

No vulnerabilities were found. The application demonstrates a strong security posture with no findings above Informational severity. TLS 1.3 with post-quantum key exchange, comprehensive security headers, strict WebSocket authentication (single-use keys, IP binding, origin validation), and a server-side message whitelist combine to provide defense in depth. Source code review of the JaWS framework confirmed the empirical findings and revealed a well-designed security architecture throughout.

Tool: Nmap 7.98 (-sV --script=http-headers,http-title,ssl-cert,ssl-enum-ciphers)

No TLS vulnerabilities detected. Post-quantum key exchange (X25519MLKEM768) provides forward secrecy against future quantum attacks.

All headers verified via curl -D- and Nmap http-headers script.

The CSP is restrictive and well-configured:

• script-src 'self' blocks inline scripts, mitigating XSS even if HTML injection occurred
• frame-ancestors 'none' prevents clickjacking (redundant with X-Frame-Options: DENY)
• connect-src 'self' limits WebSocket/fetch to same origin
• form-action 'self' prevents form hijacking

style-src 'unsafe-inline' is the only relaxation. This is a necessary trade-off: the framework sets inline style= attributes on elements during both initial rendering and dynamic updates, and CSP nonces cannot apply to style= attributes (only to <style> elements). The theoretical risk (CSS-based data exfiltration) requires a prior HTML injection primitive, which was not found.

Source code confirmed (session.go:31-38): Cookie flags are set correctly in code, not relying on framework defaults.

Tested via curl -X METHOD:

Only GET and HEAD are accepted. All other methods return 404 or 405.

Nikto confirmed: Allowed HTTP Methods: GET, HEAD

Tested via curl and Gobuster:

Unknown paths correctly return 404. No information leakage on invalid routes.

Tool: Gobuster 3.8.2 with /usr/share/wordlists/dirb/common.txt (4612 words)

Result: Only /cars discovered. No hidden endpoints, admin panels, or debug routes found.

Tool: SQLmap 1.10.2 (--batch --level=3 --risk=2 --forms --crawl=2)

Tested parameters:

• GET: jaws.rvh, jaws.rvm, jaws.s0l, jaws.s0q
• Headers: User-Agent, Referer, Cookie

Result: No SQL injection vulnerabilities. All initial boolean-based detections were confirmed as false positives caused by the real-time page content variability (WebSocket-driven dynamic updates).

Tested via WebSocket Input and Click messages with payloads including:

• <script>alert(1)</script>
• <img src=x onerror=alert(1)>
• <svg onload=alert(1)>
• <iframe src=javascript:alert(1)>

Result: No XSS vulnerabilities.

• User input sent via Input messages is reflected to other clients only via Value commands
• Client-side jawsSetValue() uses elem.value / elem.textContent (not innerHTML)
• HTML-rendering Inner commands only carry server-generated content, never user input
• CSP script-src 'self' provides defense-in-depth against inline script execution
• Source confirmed (input_widgets.go:48-52): JawsUpdate() calls e.SetValue(v), not e.SetInner()

Tool: Nmap http-csrf script

Result: No CSRF vulnerabilities found. WebSocket Origin validation (request.go:879-918) and SameSite=Lax cookies provide protection.

Tested origin validation:

Assessment: Cookie is not checked on WebSocket upgrade — authentication relies solely on the single-use jawsKey. This is a sound design: any scenario where an attacker has the jawsKey but lacks the cookie is already covered by Origin validation (blocks cross-origin) and IP binding (blocks different-IP). An XSS attacker on the same page can read the key from the meta tag, but the browser would automatically include the HttpOnly cookie in the upgrade request anyway. Cookie validation would be redundant with the existing controls.

Source code (request.go:594-601) confirms only four message types are processed from clients:

case what.Input, what.Click, what.Set:
    rq.queueEvent(eventCallCh, ...)
case what.Remove:
    rq.handleRemove(wsmsg.Jid, wsmsg.Data)

All other message types (Inner, Redirect, Reload, Alert, Delete, Replace, SAttr, etc.) are silently ignored.

Tested empirically — server-only commands sent from client:

Also tested case-insensitive bypass attempts (inner, INNER, redirect, alert): all silently ignored despite what.Parse accepting them case-insensitively. The whitelist in the process loop is the authoritative gate.

The Set message type allows clients to modify server-side JsVar state (this is the mechanism behind mouse-position sharing).

Source code (jsvar.go:196-207): Client sends Set\tJid\tpath=jsonvalue → server calls jq.Set() on Go struct → broadcasts change.

Tested attack payloads:

Go's type system prevents prototype pollution — jq.Set() validates paths against actual struct fields and enforces type compatibility.

Tool: Nikto 2.6.0

+ Target: jawsdemo.northeurope.cloudapp.azure.com:443
+ SSL: CN=jawsdemo.northeurope.cloudapp.azure.com, Issuer: Let's Encrypt E7
+ Platform: Unknown
+ Server: No banner retrieved
+ Allowed HTTP Methods: GET, HEAD
+ No CGI Directories found
+ 0 items reported

Clean scan — no vulnerabilities, no misconfigurations, no information disclosure.

Source repository: https://github.com/linkdata/jaws

• jaws.go:116-118: Uses crypto/rand.Reader wrapped in bufio.Reader
• jaws.go:270-278: nonZeroRandomLocked() reads 8 bytes → uint64, retries on zero
• Keys are cryptographically random, non-zero, and unique within the request map

The framework uses Go's template.HTML type to distinguish trusted HTML from untrusted strings:

• Input widgets (Text, Checkbox, Range, etc.) use SetValue() → sends Value command → client sets elem.value (safe, no HTML parsing)
• Display widgets (Span, Div, Label, etc.) use SetInner() → sends Inner command → client sets elem.innerHTML
• SetInner() accepts template.HTML, meaning the developer has explicitly marked the content as trusted
• Initial HTML rendering escapes attribute values via strconv.AppendQuote() (writehtml.go:48-53)

Implication: The framework itself does not create XSS vulnerabilities. However, an application developer who passes unescaped user input as template.HTML to SetInner() would create a stored XSS condition. The CSP script-src 'self' mitigates this by blocking inline script execution.

• wsmsg.go:46-73: Parse() validates message structure (requires two tabs, trailing newline)
• Validates what.What type via what.Parse()
• Validates JID via jid.ParseString()
• JSON-unquotes data field (rejects malformed strings)
• Sanitizes with strings.ToValidUTF8(data, "")

• eventhandler.go:86-95: CallEventHandlers() wraps handler calls in defer recover(), preventing panics from crashing the server
• Event handlers receive typed Go values, not raw HTML

• jaws.go:736-738: equalIP() treats 127.0.0.1 and ::1 as equivalent
• Relevant only in shared-localhost deployments (containers, dev environments)
• Not exploitable in the demo's Azure VM deployment

None.

1. Reconnaissance: Port scanning (Nmap), application fingerprinting, technology identification
2. Transport security: TLS configuration audit, HSTS verification, certificate inspection
3. HTTP hardening: Security header review, HTTP method testing, routing analysis
4. Content discovery: Directory enumeration (Gobuster), sensitive file probing
5. Injection testing: SQL injection (SQLmap), XSS via WebSocket, CSRF assessment
6. WebSocket security: Origin validation, session hijacking, protocol fuzzing, JsVar manipulation, cross-client injection, command spoofing
7. Source code review: Authentication flow, message parsing, HTML escaping model, event handler safety, key generation