06 Чер, 2025

How Static Analysis Uncovered a Hidden Reflected XSS

Background — Code-Level Blind Spots in Response Rendering

During a static code analysis of a backend module used for exchange emulation, our tooling identified a Reflected Cross-Site Scripting (XSS) vulnerability. The issue stemmed from unescaped output being written directly into the HTTP response body without sanitization.

 

While reflected XSS is traditionally identified through dynamic testing, its root causes—improper handling of user input and unsafe rendering functions—are best addressed at the source level. This finding highlights a gap in developer hygiene and reinforces the importance of secure-by-design coding practices.

Discovery — SAST Detection of Unsafe Output Sinks

The vulnerability was located in an emulator component used for mimicking exchange behaviors. The following file and line numbers were flagged:

Location:
/internal/api/emulator/response/handler.go: 406, 474, 493, 557, 657, 705, 762, 782, 892

The pattern identified across multiple code paths was the use of http.ResponseWriter.Write() to send data back to the client, without passing it through a templating engine or performing HTML escaping.

				
					_, err = w.Write(resp)
...
_, err = w.Write(resp2)
				
			

Technical Root Cause — Unsafe Output Function

Static analysis confirmed that resp и resp2 could contain user-controlled or derived input.

The core issue lies in the direct use of w.Write() for rendering data in an HTTP response. This function performs no automatic HTML escaping, making it dangerous when the content includes any portion of user input.

 

By failing to validate or encode the output, the code becomes vulnerable to a classic reflected XSS attack. An attacker may craft a URL with malicious parameters that reflect into the response, executing arbitrary scripts in the browser.

Exploitation Path — From Input to Execution

The attack vector would follow this pattern:

  1. Attacker crafts URL with a malicious payload in a query or POST parameter.

  2. Backend reflects input into the HTTP response using w.Write().

  3. Browser executes payload, assuming it’s part of legitimate content.

  4. Impact includes:

    • Theft of session tokens or authentication data.

    • Redirection to malicious websites.

    • UI redressing or phishing overlays.

Though identified in a staging emulator component, such code often shares logic with production systems or may accidentally get promoted in CI/CD workflows.

Broader Lessons — Avoiding Dangerous Output Functions

This vulnerability underscores a recurring issue in Go and other backend languages: developers using low-level output functions without output encoding. Key takeaways:

 

  • Treat all output sinks (Write(), fmt.Fprintf(), etc.) as tainted unless wrapped in a safe context.

  • Never assume staging code is immune to security requirements.

  • Use static analysis early in the development lifecycle to detect dangerous patterns before deployment.

Recommendations — Fixing the Root Cause

Use Safe Templating:

Replace w.Write() calls with HTML-escaping template rendering, e.g.:

tmpl := template.Must(template.New("safe").Parse(html))
tmpl.Execute(w, data)

Enforce Output Encoding:

Use central wrappers for rendering responses that guarantee output is encoded.

SAST Rule Enforcement:

Configure static analysis tooling to flag:

  • Use of w.Write() in web handlers.

  • Unsafe string concatenation in HTTP responses.

  • Missing use of html/template.

Treat All Environments Equally:

Enforce the same security standards in dev/staging as in production to prevent insecure logic from propagating.

Conclusion — Prevention Starts in the Codebase

This finding shows how seemingly harmless patterns in the codebase can introduce real-world risk. Reflected XSS remains a valid concern even in backend services, particularly when developers rely on manual response rendering. SAST proves its value by identifying vulnerabilities long before they reach a browser.


Серйозність: Високий
CVE Reference: Internal finding (not publicly assigned)
CVSS Score: 7.5 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N)
Affected Module: Emulator Response Handler
Exploit Technique: Reflected XSS via Unsafe Output
Exploit Path: Direct input reflection via http.ResponseWriter.Write()
Environment: Staging (with potential for promotion)

Інші Послуги

Готові до безпеки?

зв'язатися з нами