Solar-Log 200 PM+ 3.6.0 Build 99 - 15.10.2019 - Stored XSS

Stored XSS in Solar-Log 200 PM+ 3.6.0 (CVE-2023-46344): technical analysis, impact, and remediation

Summary

Solar-Log 200 PM+ firmware version 3.6.0 Build 99 (released 15.10.2019) contains a persistent (stored) cross-site scripting (XSS) vulnerability tracked as CVE-2023-46344. The issue arises when user-supplied input (a device/name field in the Smart Energy configuration UI) is stored and later rendered into the management web interface without proper output encoding or sanitization. A low-privileged user can embed HTML with event handlers which execute when a higher-privileged user views or hovers over the rendered content, enabling session theft, account takeover, or other post-authentication attacks.

Vulnerability overview and attack vector

• Type: Stored (persistent) Cross-Site Scripting (XSS).
• Affected component: Web panel configuration page (Smart Energy -> drag & drop name field).
• Attack vector: An authenticated (but not necessarily privileged) user can submit a crafted "name" string that contains HTML/event attributes. This value is stored on the device and later rendered back into the administrative UI without appropriate escaping, allowing the injection to execute in the browser context of any administrator who views the stored data.
• Potential impact: session cookie disclosure, arbitrary JavaScript running in the admin session, modification or deletion of configuration, telemetry exfiltration, or pivoting to other internal resources accessible from the device UI.

How it works (technical detail)

At a high level the vulnerability follows this flow:

• User supplies a string via the device configuration UI (the "name" field for a Smart Energy entry).
• The backend stores that raw input in persistent storage (database or configuration file) without sanitizing or validating it.
• The management interface later renders that stored string directly into a page as HTML (not as plain text), so the browser parses injected tags and event handlers.
• If the injected HTML contains an event like onmouseenter or onmouseover that executes JavaScript, then when an administrator hovers over or otherwise triggers that element, the injected code runs in the admin's browser context and can access cookies, tokens, or perform actions as the admin.

Sanitized proof-of-concept (display-only)

Below is a display-only, escaped representation of the payload that demonstrates how an attacker could embed an event handler in a "name" field. The payload is escaped so it is safe to include in this article (it will not execute here):

<xss onmouseenter="alert(document.cookie)" style="display:block">test</xss>

Explanation: This payload demonstrates the technique — it creates a custom tag with an onmouseenter handler. If an application were to render this stored value as HTML rather than escaped text, the browser would parse the tag and run the onmouseenter JavaScript when the user hovers over the element. To avoid enabling attacks from documentation, the above payload is HTML-escaped so it will not execute in the reader's browser.

Impact and example use cases

Stored XSS inside a management interface is especially dangerous because the target users tend to be privileged administrators. Possible attack outcomes include:

• Session theft: stealing cookies or tokens from an admin session, then using them to log in as the admin.
• Configuration tampering: executing JavaScript that triggers configuration changes via authenticated API calls in the admin context.
• Data exfiltration: reading telemetry, logs, or internal addresses accessible via the browser and sending them to an attacker-controlled server.
• Supply-chain or cascading attacks: leveraging admin privileges to push malicious updates or change network settings.

Detection and indicators

• Search persistent storage (database rows or config files) for strings containing '' or suspicious event attributes such as onmouseover, onmouseenter, onclick, onload, etc.
• Inspect rendered pages in the admin UI for unexpected HTML elements inside fields that should be plain text.
• Monitor webserver access logs for unusual requests that include injected payloads or suspicious characters.
• Use automated scanning tools (e.g., an authenticated Burp scan) to look for stored XSS in configuration fields. Validate results manually.

Mitigation and remediation

Primary remediation steps:

• Apply vendor-supplied patches or firmware updates. Check Solar-Log vendor advisories and upgrade to the patched firmware version. If a patch is available, install it as a top priority.
• If a patch is not yet available, restrict access to the management interface: limit network exposure, apply firewall rules, and require VPN/Azure AD or similar protections for admin access.
• Temporarily disable or restrict features that accept free-form HTML-capable fields (e.g., drag & drop name editing) until patched.
• Rotate credentials for administrative accounts and review logs for suspicious activity.
• Harden cookies (HttpOnly, Secure, SameSite) to reduce the impact of any DOM-based theft attempts.
• Implement Content-Security-Policy (CSP) headers that restrict execution of inline scripts and only allow scripts from trusted origins.

Recommended secure coding and configuration changes

To prevent stored XSS in web applications, follow these defensive measures:

• Server-side output encoding: Always encode user-supplied data when inserting it into HTML contexts. Do not rely solely on client-side sanitization.
• Input validation: Validate and normalize fields on the server using allowlists (e.g., only allow alphanumeric plus whitespace for a "name" field) and reject or normalize unexpected input.
• Escape at render-time: Use templating engines or frameworks that auto-escape values by default. Apply contextual encoding for HTML, attribute, JavaScript, and URL contexts.
• Use an allowlist HTML sanitizer (if HTML input is genuinely required) such as HTMLPurifier (PHP) or DOMPurify (JavaScript running on the server) configured to remove unsafe tags and attributes.
• Set secure headers: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and Strict-Transport-Security.

Example mitigations (code)

Below are example snippets showing safe server-side encoding and a CSP header. These are illustrative; choose an approach appropriate for your stack and validate with security testing.

// PHP: Basic output encoding when rendering a name field
// Note: htmlspecialchars encodes characters so they render as text rather than HTML.
$name = $_POST['name'] ?? '';
$safe_name = htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
echo $safe_name; // safe to include in HTML body

Explanation: htmlspecialchars converts '', '&', '"' and other special characters into HTML entities (<, >, &, ", etc.). When you echo the encoded string into an HTML document, the browser displays it as text rather than parsing it as HTML, preventing XSS execution.

// Example CSP header in PHP — prevents inline scripts and limits script sources.
// Adjust 'self' or add specific trusted script origins as required.
header(\"Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';\");

Explanation: Content-Security-Policy is a defense-in-depth control. With script-src 'self' and no 'unsafe-inline', inline event handlers and inline <script> blocks are blocked by the browser, limiting attack success even if an injected payload is present. CSP should complement, not replace, proper output encoding.

// Example: using DOMPurify on server-side (Node.js) to sanitize HTML if HTML input is allowed
const DOMPurify = require('dompurify');
const {JSDOM} = require('jsdom');
const window = (new JSDOM('')).window;
const purify = DOMPurify(window);

const dirty = req.body.name; // user-supplied
const clean = purify.sanitize(dirty, {ALLOWED_TAGS: ['b','i','strong','em','u'], ALLOWED_ATTR: []});
res.send(clean);

Explanation: DOMPurify is an allowlist-based sanitizer. Here we only permit a small set of harmless text-formatting tags and remove all attributes (including event handlers). For server-side sanitization, prefer libraries that are actively maintained and configured with explicit allowlists.

Immediate action checklist for administrators

• Check vendor site and apply any firmware updates for Solar-Log 200 PM+ immediately.
• Restrict access to the management interface (network ACLs, VPN-only, IP whitelisting).
• Search stored configuration and DB for HTML-like content in name/label fields and remove suspicious entries.
• Rotate admin credentials and invalidate sessions where possible.
• Enable and enforce secure cookie attributes and deploy a strict CSP.
• Monitor logs for anomalous activity and scan for other stored XSS locations.

Secure development guidance for vendors

• Adopt secure-by-default rendering: treat all untrusted input as untrusted and escape on output.
• Use server-side validation and sanitization; prefer allowlists to blocklists.
• Employ automated security testing (SAST/DAST) with authenticated scans of management interfaces.
• Track and fix security issues in a public advisory process and provide timely firmware updates.
• Introduce defenses-in-depth: CSP, HttpOnly/Secure cookies, and least-privilege admin roles.

References

Item	Details
CVE	CVE-2023-46344 (Stored XSS in Solar-Log 200 PM+ 3.6.0 Build 99)
Vendor	Solar-Log (https://www.solar-log.com/en/)
Recommended resources	OWASP XSS Prevention Cheat Sheet, HTMLPurifier, DOMPurify, CSP documentation