Prevent zero click account takeover

[zippunov]

Zero-click account takeover

Impact
This occurs when an attacker is logging in using "Log in with Microsoft". The application checks if the user has an existing account based on the email address provided by the Identity Provider (Azure AD) and merges the two accounts. Usually, this ensures the user identity is unified and they retain control over their account. However, in the case of OAuth, as the email address is not trusted or verified, merging user accounts results in a full account takeover by an attacker.

This OAuth misconfiguration can be used to take over accounts, without any user interaction. All an attacker needs is the victim's email address and this would lead to a zero-click account takeover.

Steps to reproduce:

1. Modify email attributes under "Contact Information" in an Azure Active Directory to the victim's email address from the Attacker's Azure AD account: victim123@gmail.com is the victim's email in our case.

2. "Login with Microsoft" using the attacker's Azure AD account and you will see the victim's email address on screen (i.e victim123@gmail.com). This means that the "email" attribute is being accepted by the web app, leading to an account takeover.

Mitigation:
Recheck if the email ID is the same as the Azure account owners. Do NOT rely on the email attribute. The User Principal Name should be used instead, or use the "sub" (Subject) claim as the unique identifier for the user and not the "upc", "email", "preferred_username" and other claims for authentication or authorization.

[techknowlogick]

Thanks for your PR. This would be the responsibility of the end-user of the library to ensure that there is no overlap/re-use of emails, as Email is not guaranteed to be unique. The fallback to the principal in this situation is just so that something is present in the email field, vs using it to uniquely identify the user.
This is similar to many other sites, such as GitHub/Twitter/etc.., where users can change their email, and username, which this would return, but the end-user of the library would need to ensure that they are using a unique identifier that doesn't change/overlap/can be modified by a user.
I think instead of modifying the behaviour, that perhaps additional documentation should be added to ensure that end-users are aware that they shouldn't use non-reliable fields for user identification.