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, newSession): 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 (lib/ui/input_widgets.go, InputText.JawsUpdate): JawsUpdate() calls e.SetValue(v), not e.SetInner()

Tool: Nmap http-csrf script

Result: No CSRF vulnerabilities found. WebSocket Origin validation (request.go, Request.validateWebSocketOrigin) 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, Request.handleIncoming) confirms only these message types are processed from clients:

case what.Input, what.Click, what.ContextMenu, 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-variant bypass attempts (inner, INNER, redirect, alert): all rejected. what.Parse matches command names exactly and case-sensitively, so case-variant payloads return the invalid zero value at parse time; the whitelist in the process loop is a second, authoritative gate.

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

Source code (lib/ui/jsvar.go, JsVar.JawsInput): Client sends Set\tJid\tpath=jsonvalue → server unmarshals the value and applies it by path (jq.Set() for a non-PathSetter bound value) → broadcasts change.

Tested attack payloads:

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

Trust boundary (application responsibility): the generic jq.Set() path will set any json-tagged field of the bound value and will append to a slice one element per Set message. The per-write size is bounded by the 32 KiB WebSocket read limit, and accumulated state is bounded by ui.MaxClientJsVarBytes (default 1 MiB) for non-PathSetter values — exceeding it aborts the Request with ErrJsVarTooLarge on the next render. There is (see I6) no per-message rate limit. A Set message is therefore only as constrained as the bound type. When binding a value where only some fields should be client-writable, or which contains a mutable/unbounded collection, the bound type must implement ui.PathSetter (JawsSetPath) to allow-list paths and bound lengths; the framework then routes client writes through it instead of jq.Set(). jawstree.Node is an example: it implements JawsSetPath to reject every path except the per-node .selected boolean, so a browser cannot rename nodes, mutate ids, or grow the children slice.

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 (New): Uses crypto/rand.Reader wrapped in bufio.Reader
• jaws.go (Jaws.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 generated attribute values with HTML entities (htmlio.AppendAttrValue)

Convenience path — plain strings are trusted too. The HTML-inner widget constructors and RequestWriter helpers (NewSpan/Span, NewDiv/Div, A, Label, Li, Td, Tr, and Button) accept an any and route it through bind.MakeHTMLGetter; the Object widget (constructed via ui.New) routes its innerHTML the same way. A plain string taken by that path is treated as trusted HTML and is not escaped — no explicit template.HTML cast is required — so that markup can be passed conveniently from templates (e.g. {{$.Span "<i>text</i>"}}). Values wrapped in a bind.Getter[string], bind.Binder[string], or fmt.Stringer are escaped. The same trust applies to the named.NewBool/BoolArray.Add HTML labels (typed template.HTML).

Implication: The framework itself does not create XSS vulnerabilities, but its XSS safety is contingent on the application developer never passing untrusted data either as a plain string to an HTML-inner widget or as template.HTML to SetInner() — doing so would create a stored XSS condition. Wrap user input in a Getter/Stringer (auto-escaped) or pre-escape it with template.HTMLEscapeString before casting. The CSP script-src 'self' mitigates this by blocking inline script execution.

• lib/wire/wsmsg.go (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 (CallEventHandlers): wraps handler calls in defer recover(), preventing panics from crashing the server
• Event handlers receive typed Go values, not raw HTML

• jaws.go (equalIP): treats all loopback addresses as equivalent so a reverse proxy connecting to the backend over loopback does not break session/request-key IP binding.
• Consequence: in any deployment where the backend sees only loopback peers — the common reverse-proxy topology (nginx/Caddy/load balancer → backend over 127.0.0.1/::1), and shared-localhost/container/dev environments — IP binding is effectively a no-op, since every client presents the same loopback address. IP binding is defense-in-depth that supplements the single-use request key and session cookie.
• Mitigation: set Jaws.TrustForwardedHeaders to bind on the proxy-supplied client IP (X-Forwarded-For leftmost / X-Real-IP) instead of the loopback transport peer. Only enable this behind a single reverse proxy you control that sets these headers.
• Not exploitable in the demo's Azure VM deployment (direct client connections; no shared loopback).

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