Add Email Validation Rules for XSS attack modes

[jobannon]

Problem

The primary mechanism to validate an email address on a User within FusionAuth is through an email verification workflow. In this workflow, policies can be set to block user access until this is complete (gating) or/and remove users after N days of non verifying an email address. Optionally, users can remain with both verified and unverified email addresses in a tenant in FusionAuth.

In either case, users can enter an email address such as

</script><script/>@something.com

In other words, we are not blocking this type of email address on User Create or Update. This does not pose a strong security threat to FusionAuth, but could pose a threat to downstream consumers of this email address (if an application integrator is not accounting for XSS and SQL injection attack vectors when consuming this email address)

Solution

Complete addition email validation to block certain email addresses from being allowed on user update and user create.

Additional context

Customer suggested

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

Internal:
We can review our current email validation rules in context of various standards for valid characters in email addresses to see if we can further restrict what is allowed.

So far we have intentionally not been overly restrictive because for every email standard describing valid characters, etc there seems to be someone that allows it. For this reason we have been someone loose and allow the email verification process to be the final arbiter. In other words, if it can be delivered, it is valid.

But we should revisit this and identify if we can safely restrict additional values w/out potentially breaking any valid use cases.

[harishreddy-m]

I tested with single quotes in email. Fusionauth registration accepts such emails.

[Aaron-Ritter]

I would +1 to validate email input in the backend and frontend visible as an error to the user. A typical mistake we find is , instead of . where a user thinks they've done everything right and because of that start to distrust the login service.

A possible solution could be the most common validation as a default and an optional list of special characters which can be specified in the email configuration.