[🐛] 401 Unauthorized unsigned/fake-signed JWT tokens

[hpacheco]

:bug: Bug report

Description

Unsigned/fake-signed JWT tokens work for the purpose of solving the JWT challenges, but Juice Shop responds with 401 Unauthorized {"status":"error","message":{}}.

Is this a regression?

This seems to be a regression of https://github.com/juice-shop/juice-shop/pull/1310

I have only tried the latest version.

:microscope: Minimal Reproduction

1. Login into Juice Shop with any account
2. Perform any authorized GET request, e.g., list basket <host>/rest/basket/<bid>
3. Check the header Authentication: Bearer <header>.<payload>.<signature>
4. base64url-decode <header>, change alg to none, base64url-encode into <unsigned_header>.
5. Resend the original <host>/rest/basket/<bid> GET Request with header Authentication: Bearer <unsigned_header>.<payload>.

If changing email to [email protected] in the payload, the unsigned JWT challenge is detected as solved.

:fire: Exception or Error

:deciduous_tree: Your Environment

v17.8.0 8.5.5

Additional Information

npm list jsonwebtoken
├─┬ [email protected] │ └── [email protected] └── [email protected]

Tested on Mac OS X 12.2 with brew-installed [email protected] Tested on Kali Linux 2022.1 with apt-installed node@ 8.5.5

[github-actions[bot]]

Thanks a lot for opening your first issue with us! 🧡 We'll get back to you shortly! ⏳ If it was a Support Request, please consider asking on the community chat next time! 💬

[bkimminich]

When you set this tampered token in the Local Storage and Cookies as token, and then visit the Shopping Basket oder Customer Feedback pages: Do you see anonymous or [email protected] as the email? If the latter, then this is the expected behavior. A fully valid "login" with a tampered token does no longer work consistently since #1310, and I'm out of ideas how to make it possible again. Would need help from someone who's actually knowlegable about JWT to help with this.

[hpacheco]

When you set this tampered token in the Local Storage and Cookies as token, and then visit the Shopping Basket order Customer Feedback pages: Do you see anonymous or [email protected] as the email? If the latter, then this is the expected behavior.

Apparently none of the above, since the user is fetched via a /rest/user/whoami GET request, with Authentication token being the forged JWT token and Cookie token being the original token, and the rest/user/whoami call actually only considers the Cookie token. Therefore I keep seeing the info of the original user in both the Shopping Basket or the Customer Feedback.

A fully valid "login" with a tampered token does no longer work consistently since #1310, and I'm out of ideas how to make it possible again. Would need help from someone who's actually knowledgeable about JWT to help with this.

After a more detailed inspection of the error messages and the code, it is clear that the reason why we do not get a "fully valid login" is due to additional checks related to the authenticatedUsers structure past the jsonwebtoken verification (done by security.isAUthorized()). For instance, with an unsigned JWT token:

• /rest/basket/<bid> does not work because the <bid> is checked against the authenticatedUsers
• /rest/order-history does not work because user email and id are checked against the authenticatedUsers
• /api/BasketItems works since only the JWT token is verified
• /api/Users works since only the JWT token is verified

IMHO it would still be nice for the JWT challenges if the fake JWT tokens could be automatically added to the authenticatedUsers structure. But as long as there are some interfaces that can be exploited with the fake JWT tokens it is interesting enough, and perhaps more reasonable. I would probably restrict the JWT challenges to particular interfaces to make them feel less artificial. Currently, a user that tries to exploit an interface with extra protections will be able to solve the challenge but see his authentication refused; this is the most puzzling part and should ideally be avoided.

FYI, I happened to realize that the /api/Users is accessible to any non-admin user. I can't remember if it is already being used somewhere else, but could serve for a new Broken Access Control challenge.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. :calendar: It will be closed automatically in one week if no further activity occurs.

[bkimminich]

Not actual issue progress, but there was some interesting discussion recently in the Juice Shop channel on OWASP Slack about the JWT issues: https://owasp.slack.com/archives/C255XSY04/p1659628380180969

TL;DR: Any help from a JWT expert to perform an as-is-analysis of our current auth process and the problems with the challenges is highly appreciated.

[Wind010]

Ooof, I was wondering why this wasn't working with api/Addresss