Chat/message renderer writes arbitrary HTML into innerHTML

[tg12]

Summary

WireTapper's chat/message renderer writes arbitrary HTML directly into innerHTML, creating a second client-side XSS sink distinct from the popup/sidebar rendering paths already identified.

Evidence

• https://github.com/h9zdev/WireTapper/blob/main/templates/wifi-search.html#L2146-L2155 defines:

function addMessage(text, type) {
  const div = document.createElement('div');
  div.className = `message ${type}`;
  div.innerHTML = text;

• The same script explicitly notes that it now supports raw HTML/code rendering.
• The page also renders other dynamic data into the DOM using innerHTML, showing a broader pattern of trusting strings as markup.

Why this matters

Any provider response, AI summary, error string, or operator-supplied content that reaches addMessage() can become executable markup in the browser rather than inert text.

Attack or failure scenario

A remote provider or reflected error returns attacker-controlled HTML. The application passes that string into addMessage(), and the browser executes the payload in the origin context of the reconnaissance dashboard.

Root cause

Presentation logic treats message strings as trusted markup instead of text content, without sanitization or a constrained markdown renderer.

Recommended fix

1. Replace innerHTML with text rendering by default.
2. If rich formatting is required, sanitize through a strict allowlist renderer.
3. Audit every call site that passes data into addMessage().
4. Add regression tests for hostile HTML in message payloads.

Acceptance criteria

• Message rendering no longer executes arbitrary HTML.
• Hostile markup is displayed inertly or removed by a sanitizer.
• Call sites are reviewed and test-covered.

Suggested labels

• security
• bug
• production-readiness

Priority

P1 (High)

Severity

High — a direct DOM HTML sink exists in the primary operator interface.

Confidence

Confirmed — the unsafe sink is explicit in source.