Sales Tracker Management System v1.0 - Multiple Vulnerabilities

Sales Tracker Management System v1.0 – A Deep Dive into Multiple Vulnerabilities

Security researchers and ethical hackers continue to uncover critical flaws in open-source web applications, especially those distributed through platforms like SourceCodester. One such example is the Sales Tracker Management System v1.0, a PHP-based application that, despite its utility for small business sales tracking, harbors multiple security vulnerabilities. This article analyzes the system’s architecture, identifies key flaws, and explores how attackers can exploit them—particularly through cross-site scripting (XSS) and poor input sanitization.

Overview of the Vulnerable System

The Sales Tracker Management System v1.0 is advertised as a free, open-source PHP application for managing sales data, user accounts, and reporting. It includes features such as user management, sales tracking, and dashboard visualization. While intended for educational or small-scale deployment, the application lacks proper security controls, making it a prime target for exploitation.

According to the exploit report by Affan Ahmed, the system was tested on a Windows 11 + XAMPP environment, confirming that the vulnerabilities are active in local development setups—indicating that the flaws are not isolated to specific configurations.

Identified Vulnerabilities and CVE

The primary vulnerability is CVE-2023-3184, categorized as a stored cross-site scripting (XSS) flaw. This occurs when user input is not properly sanitized before being stored in the database and later rendered on the frontend without escaping.

Attackers can inject malicious scripts via form fields such as firstname, middlename, lastname, and username. When these fields are rendered in the admin dashboard, the browser executes the embedded script, redirecting users to a malicious domain—e.g., //evil.com.

Exploit Demonstration

Using the provided credentials:

• Username: admin
• Password: admin123

An attacker can log in, navigate to the User List section, and use the Create New User form to inject payloads.

Reproduction Steps

Here is a step-by-step breakdown of the exploit:

1. Log in using the default admin credentials.
2. Visit the URL: http://localhost/php-sts/admin/?page=user/manage_user.
3. Fill out the user creation form with the following payloads:

• firstname: CLICK_HERE_FOR_FIRSTNAME
• middlename: CLICK_HERE_FOR_MIDDLENAME
• lastname: CLICK_HERE_FOR_LASTNAME
• username: CLICK_HERE_FOR_USERNAME

Submit the form via the Save button.

After successful submission, the new user appears in the admin dashboard.

Clicking any of the hyperlinks redirects the user to evil.com.

Technical Analysis of the HTTP Request

POST /php-sts/classes/Users.php?f=save HTTP/1.1
Host: localhost
Content-Length: 1037
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7hwjNQW3mptDFOwo
X-Requested-With: XMLHttpRequest
Referer: http://localhost/php-sts/admin/?page=user/manage_user
Cookie: PHPSESSID=r0ejggs25qnlkf9funj44b1pbn

This request is sent to the backend Users.php class, which handles user creation. The form data includes fields like firstname, lastname, and username—all of which are stored without sanitization. The absence of HTML entity encoding or input validation allows the XSS payload to persist in the database and be rendered directly in the browser.

Security Flaws and Root Causes

Flaw	Description	Impact
Stored XSS	Input fields are not sanitized before storage.	Malicious scripts execute when user data is displayed.
Weak Authentication	Default credentials are hard-coded and publicly known.	Easy access for unauthorized users.
Missing Input Validation	No checks for HTML tags or script content.	Arbitrary code injection possible.
Unescaped Output	Database values are rendered directly in HTML.	Browser interprets payload as executable code.

Exploitation Implications

While the demonstrated exploit redirects users to evil.com, the potential for real-world harm is significant. An attacker could:

• Steal session cookies via document.cookie scripts.
• Redirect users to phishing sites.
• Inject malicious JavaScript to perform DOM manipulation.
• Use the XSS as a vector for client-side attacks or chain attacks (e.g., combining with CSRF).

Moreover, since this is a stored XSS, the payload remains active until the user record is deleted—making it a persistent threat.

Security Recommendations and Fixes

To mitigate these vulnerabilities, developers must implement the following best practices:

1. Input Sanitization

Before storing user data, sanitize all inputs using functions like htmlspecialchars() or filter_input() in PHP.

// Example: Sanitizing input before storing
$firstname = htmlspecialchars($_POST['firstname'], ENT_QUOTES, 'UTF-8');
$lastname = htmlspecialchars($_POST['lastname'], ENT_QUOTES, 'UTF-8');
$username = htmlspecialchars($_POST['username'], ENT_QUOTES, 'UTF-8');

This ensures that <a href=//evil.com> is rendered as plain text, not executable HTML.

2. Output Escaping

When displaying user data in the frontend, always escape output using htmlspecialchars() or similar functions.

// In the admin dashboard
echo htmlspecialchars($user['firstname'], ENT_QUOTES, 'UTF-8');

Even if data is stored in the database, rendering it with proper escaping prevents XSS execution.

3. Strong Authentication

Replace default credentials with strong, randomly generated passwords. Enforce password complexity and require admin users to change the initial password upon first login.

4. Form Validation

Implement server-side validation to reject inputs containing HTML tags, script keywords, or suspicious patterns.

// Example: Rejecting XSS patterns
if (preg_match('/<[^>]*>|script|javascript|onload|onclick/i', $input)) {
    die("Invalid input detected.");
}

Using regular expressions can help detect common XSS vectors.

5. Use of Content Security Policy (CSP)

Implement a CSP header to restrict script execution to trusted sources:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

This prevents any external scripts from being executed—even if XSS is injected.

Conclusion

The Sales Tracker Management System v1.0 serves as a cautionary tale for developers and users of open-source software. While such tools offer convenience and accessibility, they often lack robust security features. The CVE-2023-3184 vulnerability highlights the dangers of stored XSS and poor input handling—issues that can compromise entire systems.

Security professionals must prioritize input validation,