Is the GET request containing the code parameter vulnerable in OAuth2 authentication?

Web Hacking
1

I’m currently assessing the security of an application using Oauth2 authentication.

During the Oauth dance, when authenticating with user John Doe in browser A, one of the requests is: GET https://siteImAssessing.cxx/?code=LongOAUTH2AuthorizationCode

What I’ve noticed is that I can copy and paste that GET request in a different browser (browser B) and I become John Doe in that browser as well without the need to enter John Doe’s credentials. (I receive fresh JWT tokens in browser B as well)

Would this be considered normal Oauth2 behavior or would this be worth reporting? I know that the value of the code parameter is not session cookie but it feels like it is acting as one in this case.

Additional information:

  • The value of code expires after 5 minutes
  • The value of code expires when the user refreshes the browser window in either browser A or B

Thank you,

2

Hi @BlackCat! Good question; thanks for sharing!

As far as the OAuth code logging you in as the other user, that all sounds about right. Based on the information you’ve provided, it does sound like the developer has taken some steps to mitigate potential unauthorized disclosure of the token. However, there may still be one or more vulnerabilities, such as:

  • It’s typical for OAuth flows to use a series of redirects to move the user along the process, which often involves URIs that contain tokens. However, if the final redirection leaves such a token in the user-visible URI (i.e. in the address bar), I think it could qualify as a P4 - [Sensitive Data Exposure \ Sensitive Token in URL \ User Facing] (see VRT). Exploitability (and thus whether it’d qualify as a bug) will turn on whether the token can be reused.

  • The OAuth access token should be one-time use, such that once it’s been used to retrieve session token(s) in Browser A, the OAuth access token is invalidated and cannot be used to retrieve any further session token(s). In other words, the application should be implementing some anti-replay protections. I think a key fact here is whether the access token is being used to login via Browser B before or after the user has completed logging via Browser A. If it can be reused after, then I would suggest it should qualify as a valid bug, because:

    • While the VRT doesn’t capture this specific scenario, it does include a P4 for [Insufficient Security Configurability \ Weak Password Reset Implementation \ Token is Not Invalidated After Use], which aligns pretty well with your situation.

    • You don’t mention whether the OAuth query includes a state parameter but if this is missing, that’s definitely a problem. The state parameter is applicable in this context because it should be acting to prevent this sort of attack…basically like CSRF protection for the OAuth flow.

Here are a couple other things you may also want to test:

  • At what point is the application binding the OAuth access token to the user’s account and can you effectively achieve session fixation (P3) by attacking this process.

  • Is the application vulnerable to open redirection, such that an attacker could use a malicious redirect to steal the access token and then chain that with the above replay vulnerability to gain unauthorized access to the user’s account.

Here are a couple really good resources when testing OAuth:

If you do decide to submit it, let know how it turns out, as it’ll be a learning opportunity either way. Good Luck!

– nerdwell

2 Likes