Description

A Cross-Site Scripting (XSS) vulnerability has been identified in the application. User-controlled data is returned in HTML responses without proper encoding, allowing the injection and execution of arbitrary JavaScript code in users’ browsers.

Depending on the context (reflected, stored, or DOM-based), this vulnerability can be exploited to compromise sessions, perform actions on behalf of users, or redirect them to malicious content.

Code analysis shows that the checkValidHtmlText() function in Security.php only uses regular expressions to detect certain patterns (<script>, JavaScript events) without applying any real encoding or sanitization:

Codepublic static function checkValidHtmlText($string) {
if (preg_match('/<script/', pq_nvl(pq_strtolower($string))) == true) {
traceHack("invalid sequence in html text - $string");
}
if (preg_match('/onload|onshow|onclick|onchange|onmouseover|onmouseout|onkeydown|
beforeunload|blur|oncontextmenu/', pq_nvl(pq_strtolower($string))) == true) {
traceHack("invalid sequence in html text - $string");
}
return $string;
}

This method is insufficient: it does not effectively block modern XSS vectors and does not ensure proper escaping before rendering data on the client side.

Attack Vectors

• Network access: Remote
• Authentication required: Low
• User interaction: Required (victim loads malicious content)
• Scope: Changed (script executes in the victim’s browser context)
• Type: Stored
• Injection point: [search field, profile field, comment, HTTP header, etc.]

Steps to Reproduce (PoC)

Testing shows that several application endpoints are vulnerable to XSS injections. It is possible to bypass existing filters using alternative payloads such as:

Code<img src onerror=alert(1)>

This payload demonstrates that JavaScript execution is still possible despite filters targeting only specific tags (notably <script>), confirming the ineffectiveness of the current protection mechanism.

As an example, a POST request sent to the /tool/ack.php endpoint, injecting the payload into the resultAck parameter, triggers client-side code execution.

Figure 1 :

The associated screenshot confirms successful exploitation. Figure 2 :

Impact

Successful exploitation of this vulnerability may lead to significant impacts, including:

• Session compromise and hijacking
• Execution of actions on behalf of the user (CSRF-like behavior)
• Redirection to phishing websites
• Interception of user inputs (e.g., credentials)
• Modification of application interface integrity

Possible Mitigation

To fix this XSS vulnerability:

1. Server-side encoding: sanitize all user input before output. Example in PHP:

Codeecho htmlspecialchars($userInput, ENT_QUOTES | ENT_HTML5, 'UTF-8');

2. Whitelist-based filtering: allow only safe HTML tags, for example using HTMLPurifier:

Coderequire_once 'HTMLPurifier.auto.php';
$purifier = new HTMLPurifier();
$cleanHtml = $purifier->purify($userInput);
echo $cleanHtml;

3. Client-side CSP: implement a Content Security Policy to restrict execution of unauthorized scripts.

Objective: prevent injection and execution of malicious JavaScript while still allowing safe rendering of user content.

Authors

• Yassine Damiri
• Noé Susset