Because the injected script executes in the context of the victim's authenticated session, a successful exploit can be used to:

• Steal session cookies and hijack the user's management console session.
• Perform unauthorized actions on behalf of the victim (privilege escalation, configuration changes, etc.).
• Deliver phishing content or redirect the victim to a malicious site.
• Capture keystrokes or sensitive data entered into the management console.

Affected Component

Vulnerability Details

Root Cause

The eScan Management Console web application accepts user-controlled values through the Dtltyp and ListName GET parameters and includes them in the HTML response body without performing adequate input validation, output encoding, or Content Security Policy (CSP) enforcement. This unsanitized reflection of user input allows an attacker to inject arbitrary HTML/JavaScript that will execute in the browser of any user who loads the crafted URL.

Attack Vector

1. The attacker crafts a malicious URL containing an XSS payload in the Dtltyp or ListName parameter.
2. The attacker tricks a logged-in eScan Management Console user (e.g., an administrator) into clicking the link — via phishing email, social engineering, or a watering-hole attack.
3. The console server reflects the payload back in the HTTP response.
4. The victim's browser executes the injected script within the context of the eScan Management Console origin.

Example Payload

URL-encoded form (as it would appear in an actual HTTP request):

Note: The exact URL structure will depend on your target installation. Replace <target> with the IP address or hostname of the eScan Management Console server.

Proof of Concept

Step 1 — Log In and Navigate to the Vulnerable Feature

Log in to the eScan Management Console with valid credentials and navigate to User Activity → File Activity Report.

Step 2 — Intercept the Request

Use an HTTP interception proxy (e.g., Burp Suite) to capture the GET request sent when the report page loads.

Step 3 — Inject the XSS Payload

Modify the captured request by injecting an XSS payload into the Dtltyp and/or ListName parameters, then forward the request to the server.

Step 4 — Observe Code Execution

After forwarding the request, the injected script executes in the browser. The screenshot below shows an alert pop-up triggered by the payload. This payload can be modified to exfiltrate the victim's session cookie or perform other malicious actions.

Impact

Remediation

Microworld Technologies should address this vulnerability by implementing the following mitigations:

1. Output Encoding: All user-controlled values reflected in HTML responses must be HTML-escaped (context-aware output encoding) before insertion into the response body. Use a well-tested encoding library rather than manual string replacement.
2. Input Validation: Reject or sanitize input that does not conform to the expected format for the Dtltyp and ListName parameters (e.g., allow-listing acceptable values).
3. Content Security Policy (CSP): Deploy a strict Content-Security-Policy HTTP response header to limit the sources from which scripts can be loaded and to block inline script execution.
4. HttpOnly & Secure Cookie Flags: Mark all session cookies with the HttpOnly and Secure flags to reduce the impact of any future XSS vulnerabilities.
5. Regular Security Audits: Conduct periodic penetration tests and code reviews of the web-facing management console to identify and remediate similar issues proactively.

References

• NVD — CVE-2023-34836
• MITRE CVE Record
• OWASP: Cross-Site Scripting (XSS)
• OWASP: XSS Prevention Cheat Sheet
• Microworld Technologies eScan

Disclaimer

This proof-of-concept is published for educational and security research purposes only. Exploiting vulnerabilities on systems without explicit written permission is illegal and unethical. The author takes no responsibility for any misuse of the information provided herein.