[⭐] OAuth2.0 implicit flow exposing access token

[ThReinecke]

:star: Challenge idea

Description

I would like to propose a new challenge for OAuth2.0. The Juice Shop uses the implicit flow. I think there is a great opportunity to show why this flow is considered insecure. The implicit flow, which is initiated by requesting the response_type 'token', is insecure as it transports the access token in the url. If an attacker is able to execute malicious javascript in the browser (XSS) or gain access to the browser session otherwise, the attacker can get the access token by simply checking the browser history.

I think it will be hard to show an ideal example where a different user has an existing session, and the challenge would be to inject a malicious script in a XSS vulnerabilities that steals the token and sends it to the attacker. Maybe the easiest way to raise awareness for the issue of the implicit flow is by leaning on the 'Login Bjoern' challenge.

The challenge could be something like: Exploit an OAuth design flaw and steal Bjoern 'subject' claim. And then to verify that the challenge is solved, maybe submitting that subject claim in a complaint.

The sub claim might not be the most interesting data to steal, and it might not be the most real-life example, but I think it shows the issue of the OAuth implicit flow very well.

I think it would also be a great fit for a corresponding code challenge where the user would need to select response_type=token as the issue, and the fix it would be, for example, response_type=code, which initiates the more secure Authorization Code flow.

Underlying vulnerability/ies

Exposed token during OAuth implicit flow https://oauth.net/2/grant-types/implicit/

Expected difficulty

I'd give it a 4.	:heavy_check_mark: / :x:	Difficulty
:grey_question:	:star:
:grey_question:	:star::star:
:grey_question:	:star::star::star:
:heavy_check_mark:	:star::star::star::star:
:grey_question:	:star::star::star::star::star:
:grey_question:	:star::star::star::star::star::star:

Possible attack flow

The attacker logs in with an OAuth flow and Bjoerns gmail. By intercepting the requests or looking through browser/request history, the hacker gets the access token. The attacker can then do a request to the oauth userinfo endpoint like: curl -H "Authorization: Bearer " https://www.googleapis.com/oauth2/v1/userinfo to get the "sub" claim.

If there is interest, I'm happy to contribute :)

[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.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.

[ThReinecke]

If you assign the issue to me, I could start working on it. It might also be an option to introduce a custom claim whose value is a flag. This could be more 'catchy' than the sub claim, but it will need more effort and changes in the scopes and authorization server config.

[bkimminich]

I'm more than happy to let you take this up, b/c I'm really not an OAuth expert myself. We should be careful not to overburden users with too many different tasks on my Gmail user, as it's also the victim in the Login Bjoern ⭐⭐⭐⭐-challenge, which is built around an OAuth flow break already.

[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.