CSRF vulnerability in the NextAuth Email provider

[igordanchenko]

Description 🐜

Hi,

I want to report CSRF vulnerability in the NextAuth Email provider.

The issue here is that NextAuth does not verify that the "magic link" authentication request is coming from the same browser that requested it in the first place (csrf-token cookie is not getting validated).

Scenario:

1. Malicious user generates Email sign-in link using their email address
2. Malicious user emails that link to Legit user
3. Legit user clicks the link from the email
4. Legit user is now authenticated as Malicious user

To eliminate this flaw, NextAuth could:
a) derive email verification token from csrf token
b) perform csrf cookie validation during authentication call

This issue was reported to [email protected] on 6/23/2021 as per security guidelines, but there was no response.

Is this a bug in your own project?

No

How to reproduce ☕️

See scenario above

Screenshots / Logs 📽

No response

Environment 🖥

N/A

Contributing 🙌🏽

Yes, I am willing to help solve this bug in a PR

[balazsorban44]

Thank you for your concern and reaching out.

I think this has been touched on in the past, and Iain actually gave a detailed explanation here, why this is not an actual issue in our case:

#1051 (comment)

Also #1913 (comment) might be similar in spirit.

If you have further concerns, maybe you could create a reproduction?

[igordanchenko]

Thank you for sharing the additional context on this topic. If this is by design, may I suggest this be clearly documented in the Email provider documentation? I believe it will be beneficial for NextAuth users to be aware of how email links work in NextAuth. I'm sure some NextAuth users may see this as a security flaw the way I do (and in my opinion it's clearly a CSRF vulnerability).

I also looked into the documentation of the major commercial authentication providers, and it seems like none of them allow magic link authentication to take place outside of the original browser/device context.

1. Magic - https://magic.link/docs/introduction/security#phishing-protection

Plus, if a magic link email is lost or stolen (or even somehow compromised in transit), a user's account is safe! The token included in the magic link email is only privileged to verify a login request from the device and/or browsing context that initiated the request. An attacker would require physical access to the user's device and unencrypted email inbox to be malicious.

2. Auth0 - https://auth0.com/docs/connections/passwordless/guides/email-magic-link

With magic link transactions, both the initial request and its response must take place in the same browser or the transaction will fail. This is particularly relevant for iOS users, who cannot change their default web browser. For example, the user might make the initial request using the Chrome browser, but when the user opens the magic link in their email, iOS automatically opens it in Safari (the default browser). If this happens, the transaction will fail.

3. Okta - https://help.okta.com/oie/en-us/Content/Topics/identity-engine/authenticators/configure-email-authenticator.htm

When end users sign in or try to recover their password or unlock their account, they receive an email message containing the email magic link and a one-time password (OTP) code.
If users click the link in the same browser session, they’re sent to a consent page in a new tab and asked to verify that they made the request. If they affirm the request, they’re asked to return to the original tab to continue.
If users click the link in a separate browser session (or on a different device), the consent page is presented in a new browser tab where they clicked the link. Again, when they affirm their consent, they’re asked to return to the sign-in tab in the original session.

[igordanchenko]

The lack of anti-CSRF measures in the magic link authentication flow is equivalent to the lack of a CSRF prevention mechanism in the username/password authentication form. It exposes a website to the same attack vectors.

Here are some articles highlighting the importance of anti-CSRF measures in the authentication process.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf
https://seclab.stanford.edu/websec/csrf/csrf.pdf (Section 3)

[balazsorban44]

I'm aware of the importance of CSRF, but the original implementation of the Email provider wasn't done by me and I trusted the creator of their research. @iaincollins did study OWASP and I'm pretty sure that he intended to follow their guidelines.

Thank you for bringing up other examples. Iain is unfortunately less active nowadays, but I'll try to discuss this with the rest of the team to decide what the next step should be.

[balazsorban44]

Iain reached out and he told me he will share his opinion on this once he finds the time, but in short, we do not concider it as an actual vulnerability, and it does not fall under CSRF either.

[igordanchenko]

I'm honestly failing to see how it's not a CSRF as it does look like a textbook CSRF.

I'll await Iain's explanation, but in the meantime, I thought I would provide a code sandbox demonstrating the issue.

https://codesandbox.io/s/hardcore-kowalevski-nv6x0

Steps to reproduce:

1. Open browser A (this is your victim's browser) and navigate to https://codesandbox.io/s/hardcore-kowalevski-nv6x0
2. Click the 'Sign In' link and enter 'victim@localhost' as the email address
3. Grab the verification link from the sandbox Terminal log and navigate to it in a new browser tab
4. You are now signed in as 'victim@localhost'
5. Open browser B (this is your attacker's browser) and navigate to https://codesandbox.io/s/hardcore-kowalevski-nv6x0
6. Click the 'Sign In' link and enter 'attacker@localhost' as the email address
7. Copy the verification link from the sandbox Terminal log
8. Switch back to the victim's browser A and navigate to the link from the previous step. This step represents the attacker tricking an unsuspecting victim into clicking a malicious link.
9. The victim is now signed in as 'attacker@localhost'

[balazsorban44]

I will quote what he wrote as-is until he gets around this issue to hopefully shed some more light on his thoughts if you won't be satisfied with the following:

Hello,
FYI we have had this raised before. This is not a CSRF vulnerability, in that email auth cannot be an HTTP Post request.
This is an incorrect use of the term CSRF vulnerability, but it is a design limitation of the email flow (and most email flows).
There are things that can be done to mitigate it, such as shorter token durations, but it also has an impact on how the email flow can be used - the email flow allows sign-in from browsers other than the one that was used to initiate the flow by design.
...
To be clear, this is a common and deliberate pattern for email sign-in tokens - lots of platforms work this way. (including the sign-in methods for OpenCollective accounts!); changing the behavior also changes the flow.
...
It's definitely come up before and probably needs to go in the FAQ so can be pointed to.

@iaincollins is right. I just verified this with OpenCollective. I sent an e-mail to myself on my phone from my main browser, then switched on VPN, disconnected Wi-Fi (to use cellular data), opened a totally different browser in incognito mode, pasted the link I got in my e-mail, and it successfully logged me in.

Read more about this here: https://docs.opencollective.com/help/product/log-in-system#about-security

TLDR; they recite a company specialized in penetration testing:

In 2020, this login system was audited by Cure53. Their report included recommendations for improving it, but they found no critical issue nor design issue about the way it works today.

I guess you are also not wrong that this flow could be made more secure only by allowing the same browser context to execute the login flow, but this would be at the cost of convenience. And this has already been discussed in #1051 as a possible optional enhancement.

We could definitely mention this in the documentation though, so if you feel this is important, please open a PR!

[igordanchenko]

This is not a CSRF vulnerability, in that email auth cannot be an HTTP Post request.
This is an incorrect use of the term CSRF vulnerability

I will leave this up to dictionary police how to properly call this flaw, but CSRF is not limited to HTTP POST calls. https://owasp.org/www-community/attacks/csrf#get-scenario describes pretty much identical scenario with HTTP GET call.

I just verified this with OpenCollective. I sent an e-mail to myself on my phone from my main browser, then switched on VPN, disconnected Wi-Fi (to use cellular data), opened a totally different browser in incognito mode, pasted the link I got in my e-mail, and it successfully logged me in.

Hmmm... I would trust Magic, Okta and Auth0 more on this...

I guess you are also not wrong that this flow could be made more secure only by allowing the same browser context to execute the login flow, but this would be at the cost of convenience.

Agree. Some users may get upset when they initiate login in Chrome but magic link opens in Safari and transaction fails. Security can't be convenient in 100% cases.

[balazsorban44]

I, unfortunately, don't have the deep knowledge to try convincing you further, will leave it to @iaincollins. But I do think OpenCollective is a big enough actor that if that this flow works for them, it will work for many (Yes, probably not everybody). As mentioned they have been audited by professionals who did give suggestions for improvement but did not find the login process flawed.

[hillac]

Is there a work around to enforce sign in from the same browser?