Security Vulnerability: Lack of Access Token Signature Verification

[GuillemPM]

Description

Overview

Upon user login to the Reduced.to platform, an access_token is generated and stored as an HttpOnly cookie. However, the access_token lacks signature verification, enabling an attacker to manipulate the JWT token's payload. Exploiting this vulnerability allows unauthorized users to elevate their privileges by modifying the access_token cookie, granting them access to protected features, such as those restricted to ADMIN roles.

Steps to Reproduce

1. Log in to Reduced.to.
2. Obtain the access_token cookie.
3. Decode the access_token payload.
4. Modify the payload, specifically changing the role from USER to ADMIN.
5. Update the access_token cookie with the manipulated payload.

Expected Behavior

Access tokens should be securely signed to prevent tampering. Any attempt to modify the token payload should result in invalidation of the token.

Actual Behavior

The access_token lacks signature verification, allowing an attacker to modify the payload and update the access_token cookie, thereby gaining unauthorized access to elevated roles and protected features.

Proposed Solution

Implement JWT signature verification for access/refresh tokens on server side to ensure their integrity and prevent tampering.

Screenshots

Additional information

No response

[origranot]

Hey @GuillemPM, I am so happy to hear from you!

You are right, there is no jwt signature check on the Qwik server. Although we are using the backend (nest) as our API and for database access, we do check the jwt over there.

You are right, visually you have an "admin" access but you can't do nothing with it. I think we can solve it using an internal shared library that handle authentication and JWT operation for both Qwik server and backend.

What do you think, do you want to work on that issue?

[ymoukhli]

Hello @origranot,

i can work on this issue if no one wants it.

[origranot]

Hello @origranot,

i can work on this issue if no one wants it.

@ymoukhli, Hey, That's sounds good, I assigned you to this issue 💯

[GuillemPM]

@origranot I've reviewed PR #698 and identified an issue with the frontend relying on the JWT payload to determine which menus are loaded. Here are two suggestions to address this:

• Ensure the cookie is updated from the server-side with each request. This will ensure that the cookie always reflects the latest user context from the server, reducing the risk of tampered payloads. However, this approach may increase server-side bandwidth usage.

• Instead of using the cookie JWT payload to display hardcoded data (menus), we should rely solely on the server. When loading the profile page, menu tabs should be fetched from the server API. This way, the server and database become the sole trusted sources of data. Then we should discuss how to handle this scenario, might be creating a table in database to map pages/menus to user roles... Might be an easy modifiable JSON file parsed in backend...

• (My preferred solution) Fetch the role of the user when loading the page instead of relying on the cookie JWT payload, then show the menus according to that role, if we decide to use this method we wouldn't need to modify the database and access of pages would be handled by frontend.

I can help to extend more the idea of the preferred solution if needed.