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!