Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include check that access token was actually successfully returned #144

Merged
merged 2 commits into from
Sep 24, 2021
Merged

Conversation

ben12385
Copy link

getOAuthAccessToken returns an error only if it is a HTTP error, if the identity provider does not follow OAuth2 standard and instead returns a status 200 indicating it is an error, authentication can still happen. I have therefore included a check to ensure some value for accessToken must have been returned. It is done here instead of the OAuth library because I saw that the OAuth library was last updated in 2017.

Do let me know if you have any concerns (not sure if will impact passport-facebook) and thank you for creating Passport and the various modules.

Separately, I have also raised a CVE for this so that everyone is more aware of this since if the identity provider returns unsuccessful but is a status 200, an empty authorization token to the callback URL will deem the user authenticated to the application.

@jaredhanson jaredhanson merged commit 4f8f86c into jaredhanson:master Sep 24, 2021
@jaredhanson
Copy link
Owner

I don't actually believe this constitutes a security vulnerability. That being said, there is clearly no harm in this so I've merged and published [email protected] incorporating this patch.

As a result of this PR being opened, Snyk also contacted me asking for an assessment. Since this is public at this point, I've written up my assessment on the blog: https://medium.com/passportjs/no-access-token-no-service-7fb017c9e262

@ben12385
Copy link
Author

ben12385 commented Sep 25, 2021

Hi Jared, just read your post and wanted to clarify on why I thought that this is a security vulnerability. The reason why this was found is because I was testing this library for authentication to a on-prem COTs IdP which actually lead me to discover that I am able to authenticate with an empty token. I can show a demo separately if you would like.

There are multiple caveats to this though:

  1. IdP does not follow OAuth2 protocol and return 200 instead of 400 for invalid access token.
  2. No further use of the access token or no error check when using the access token

The reason why I decided to bring this up as a vulnerability here instead of at the IdP level is more of an easy fix compared to checking and ensure that the IdP follows OAuth2 standard correctly. Apologies if this has caused any trouble for you.

Mitre had assigned it CVE-2021-41580.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants