Jorani v1.0.3-(c)2014-2023 - XSS Reflected & Information Disclosure

Security Vulnerabilities in Jorani v1.0.3: Reflected XSS and Information Disclosure

Recent security assessments have revealed critical vulnerabilities in Jorani v1.0.3, a widely used open-source HR management and leave tracking system. The application, hosted at demo.jorani.org, is vulnerable to reflected Cross-Site Scripting (XSS) and information disclosure, both of which pose significant risks to users and administrators alike. These flaws were identified by cybersecurity researcher nu11secur1ty on August 27, 2023, and are classified as high severity.

Understanding Reflected XSS in Jorani

Reflected XSS occurs when user input is directly echoed back in the application’s response without proper sanitization. In Jorani v1.0.3, the language parameter in the login form is particularly vulnerable. This parameter is used to set the user interface language, but its value is directly embedded into a JavaScript string without escaping.

POST /session/login HTTP/1.1
Host: demo.jorani.org
Content-Type: application/x-www-form-urlencoded
...
language=en-GBarh5l%22%3e%3cscript%3ealert(document.cookie)%3c%2fscript%3ennois

The payload en-GBarh5l"alert(document.cookie)ennois is submitted via the language parameter. When processed, the application outputs this string unmodified within a JavaScript context, effectively injecting malicious code into the browser.

This behavior is dangerous because:

• Any attacker can craft a URL containing malicious JavaScript.
• When a user clicks such a link, the script executes in their browser context.
• Since the script is executed in the same origin as the application, it can access sensitive data like session cookies and CSRF tokens.

Information Disclosure: A Hidden Threat

Alongside XSS, Jorani v1.0.3 exposes sensitive server-side information through improper error handling. When the malicious payload is submitted, the application returns a PHP error message:

A PHP Error was encountered
Severity: 8192
Message: strlen(): Passing null to parameter #1 ($string) of type string is deprecated

This error reveals internal PHP behavior and debugging details, which can be exploited by attackers to infer:

• Application architecture and framework usage (PHP 8.2).
• Server configuration and error reporting settings.
• Potential weaknesses in input validation logic.

Such information disclosure can aid in crafting more sophisticated attacks, including privilege escalation or session hijacking.

Exploitation Scenario: Session Hijacking

Consider a real-world scenario where an attacker crafts a phishing email containing a link like:

http://demo.jorani.org/session/login?language=en-GBarh5l%22%3e%3cscript%3ealert(document.cookie)%3c%2fscript%3ennois

If a user clicks this link, the browser executes:

alert(document.cookie)

This script alerts the user with the contents of their cookie, which includes the jorani_session token. An attacker can capture this token and reuse it to impersonate the user, gaining full access to their account.

Moreover, since the csrf_cookie_jorani is also exposed in the response, the attacker can bypass CSRF protections and perform unauthorized actions.

Root Cause Analysis

The vulnerabilities stem from poor input handling in the login form processing logic. Specifically:

• Input from the language parameter is not sanitized before being embedded in JavaScript.
• PHP error messages are not suppressed in production environments.
• Session tokens are not properly protected during error responses.

These issues reflect a lack of secure coding practices, particularly in handling user-controlled data and error reporting.

Recommended Mitigations

To remediate these vulnerabilities, the following security measures are essential:

• Input Sanitization: All user input, especially parameters like language, must be validated and escaped before being rendered in JavaScript.
• Output Encoding: Use htmlspecialchars() or similar functions to encode special characters in PHP output.
• Error Suppression: Disable detailed error messages in production. Use generic error pages instead.
• Session Protection: Ensure session tokens and CSRF cookies are not exposed in error responses.
• Content Security Policy (CSP): Implement CSP headers to block inline scripts and restrict script sources.

Corrected Code Example

Here’s a secure version of the vulnerable code snippet:

// Vulnerable (original)
echo 'var language = "' . $_GET['language'] . '";';

// Secure (corrected)
$language = htmlspecialchars($_GET['language'], ENT_QUOTES, 'UTF-8');
echo 'var language = "' . $language . '";';

By using htmlspecialchars(), special characters like ", <, and > are converted to their HTML entities, preventing script injection.

Conclusion

Jorani v1.0.3’s reflected XSS and information disclosure vulnerabilities highlight the importance of secure input handling, error management, and output encoding. These flaws can lead to full account compromise, especially when combined with social engineering tactics.

Organizations using Jorani should immediately:

• Upgrade to a patched version.
• Implement strict input validation.
• Disable debugging in production.
• Apply security headers like Content-Security-Policy.

Failure to address these issues exposes users to real-world attacks that can compromise data, privacy, and system integrity.