Whatever the web application, it is common practice to allow users to change their email address. This functionality is critical because it has a direct impact on account management. Furthermore, the email address is often used as an identifier for authentication. It is therefore essential to secure this functionality.
There are several different situations. In some cases, the application allows users to change their own email address. In other cases, an administrator can change users’ email addresses. Sometimes, both options are possible.
In this article, we will detail the best practices to follow. We will then look at concrete cases of configurations encountered during audits, followed by examples of attacks.
What are the Best Practices for Implementing the Email Change Functionality?
Even if there are specific solutions depending on the context and security needs, here are the general best practices to put in place.
Users change their own email address
Once again, this functionality is critical. We recommend asking the user who wishes to change his email address to enter his password (or a 2FA code) when making the request.
And the password sent with the email change request must be verified on the server side. This ensures that the request actually comes from the legitimate user.
Once the password has been validated, it is essential to check that the user is actually modifying their own account. This check must also be carried out on the server side.
An email should then be sent to the new address provided. However, it is important to ensure that this address is in a valid format.
The email must validate that the user has access to this new address. For example, it could contain a URL with a unique token, valid for a limited period.
Finally, once the user clicks, the new email address is validated. Only then is the email address associated with the account changed in the database.
After use, the token must be revoked on the server side. If the confirmation email is never used, the new email address should not be taken into account.
Note: Wherever possible, we also recommend applying email address confirmation when creating an account. This ensures that the user has access to the specified email address. In all cases, the ideal solution is not to provide access to the web application until the email has been validated.
An administrator changes a user’s email address
For privileged administrator accounts, we recommend forcing the systematic use of the 2FA. When an administrator changes the email address of another user, a 2FA code must be requested to validate the change.
The following rules must be applied:
- The user making the change must not be able to change the email address of a more privileged user or a user with the same level of privilege. The change must only be made for a less privileged user.
- The user making the change must have access to all the organisations of the user concerned and have administrative rights on each of these organisations. Otherwise, the change request must be rejected.
If these rules are respected, the user concerned should receive an email at the new address to confirm that he has access. The email can follow the procedure described above. Once access to the mailbox has been confirmed by clicking on the confirmation URL, the change can be taken into account. If the new email address is never validated, the old address must remain associated with the account.
Examples of Email Change Configurations Encountered During Pentests
During our web application audits, we came across several cases of misconfiguration. Here is a list of these configurations with references to the attack scenarios described in the next section.
No control over email changes
This is the most problematic case, where the web application allows an account’s email address to be changed without any checks being carried out. A user can therefore change his email address or those of other users without validating access to the new email address.
This raises security and account management issues. There is no guarantee that the user has access to the new email address.
Fortunately, this kind of total lack of control is becoming increasingly rare for the functionality for changing email on one’s own account. However, it is still often the case that an administrator changes the email address of a user he manages without any control.
The consequences can vary: account takeover, total compromise of an organisation’s data, and so on.
In this case, the application is potentially vulnerable to the four attack scenarios described in the following section.
The new email address is validated without identity verification
In this case, the new email address must be validated by the user. Generally, an email is sent to this new address, containing a link or a unique code to confirm that the user has access to the email box. The change of email address will only be effective after this validation.
Although this method proves access to the mailbox, it does not prevent abuse, especially if there are problems with rights to the functionality. See cases 1, 3 and 4 in the next section for more details.
The user’s identity is validated without verification of the new address
In this situation, the user requesting the email change must prove their identity, but does not need to validate the new email address.
Identity is verified by providing a secret at the time of the request, such as the account password, the answer to a secret question or a 2FA code. Although this verification is good practice, it is insufficient, especially for a privileged user who manages other users on a multi-organisation platform.
This allows the scenario described in case 2 in the next section. And in the event of a lack of rights control, the scenarios in cases 1 and 3 are also possible.
Validation on the old email address but not the new one (or on both)
In this case, an email confirming the change of email address is sent to the old address (and sometimes to the new one too). This email indicates the new address that will be used. The change will not be effective until the user clicks on the validation link.
This method is the most secure, as it proves that the user has access to the old address and informs them of the new one. However, the main problem is that users generally want to change their email address because they no longer have access to the old one. As a result, this method is rare and often unsuitable for web platforms.
Validation of user identity and new email address
This is the best solution for a web application. It prevents almost all attacks.
However, in the case of a privileged user who manages other accounts on a multi-tenant platform, risks of account theft may remain if certain controls are not applied.
An example of this risk is presented in case 3 in the following section. Case 1 is also possible.
Attacks and Exploitations of Email Change Vulnerabilities
IDOR vulnerability on the email change feature
Let’s imagine a feature that lets you change a user’s email address. The HTTP request could be as follows:
POST /api/user/21/emailupdate HTTP/2
Host: example.vaadata.com
Cookie : sess_id =whatever
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0
Content-Type: application/json; charset=utf-8
Content-Length: 36
{"password":"mysecret", "new_email":"[email protected]"}We can see in the URL that the user ID is transmitted (here 21). The password of the logged-in user is also requested.
However, this password is associated with the user’s session and not with the identifier in the URL.
If an IDOR-type right problem exists, a malicious user could change another user’s email by modifying the identifier in the URL (for example, by setting the ID to 22).
This would lead directly to the theft of the account bearing ID 22. The attacker could specify an email belonging to him in the change request, then use the forget password feature to retrieve the password change link. In this way, he could gain access to any account.
This may seem trivial, but it happens regularly. The solution is to set up a rights check to ensure that the user making the request has the necessary authorisations to change another user’s email.
Denying access to the application for a legitimate user
This problem occurs when the email address provided is not validated on the server side.
A user can then associate any email address with their account, including one that does not exist but is not their own, to prevent another user from accessing the application.
Another vulnerability observed during pentesting consists of changing the account’s email address to that of another existing account. If the change is accepted, two accounts can end up with the same email address, potentially making one or both accounts inaccessible during authentication.
In very specific cases, such as when an SSO connection is possible and password authentication is also authorised, this can lead to a vulnerability known as a pre-account takeover.
For example, if a user can log in via Google SSO, an attacker could change the email address of their own account to that of a user who does not yet have an account.
When the legitimate user uses SSO to create an account, he is redirected to the attacker’s account because the email address is already in use. The legitimate user thinks he is logged into his own account, while the attacker can log in via email/password authentication and access the legitimate user’s data.
To avoid this problem, it is crucial to validate the email address by asking the user to click on a unique link before accepting the change. In this way, an attacker will not be able to change the email address to one to which he does not have access.
Privilege escalation in the case of a platform with many organisations
Controls are often less strict for privileged users, because they are assumed to be benevolent. However, major vulnerabilities can arise as a result of this lack of control, especially in multi-tenant environments where the consequences can be serious.
In this example, which has been encountered several times in pentesting, we need to imagine a web platform managing several distinct (multi-tenant) organisations.
Each organisation has administrators who can invite users and modify their settings. In addition, a user can be a member of several organisations.
An administrator can change the email addresses of users in their organisation. To access another organisation, simply change the email address of a user who is a member of several organisations (such as another administrator or an existing user).
Another method is to invite an existing user to join their own organisation, and then change their email address once the invitation has been accepted. All that’s left to do then is to use the forgot password feature to gain access to the account.
Third-party attacks
When the user’s password is not requested when the email is changed, there is a risk of a walk-by attack.
If a user forgets to log off, a malicious person can change the account’s email address and gain remote access via the forgotten password function. However, the likelihood of this attack being exploited is very low.
It is also possible to encounter a Cross Site Scripting (XSS) vulnerability, which is common in web applications. For example, an attacker could submit the email change form with his own email address as the new address for the targeted user.
This vulnerability can be avoided by asking for the password or another secret when changing the email address.
Author: Yoan MONTOYA – Pentester @Vaadata