Fosuserbundle: No protection from using email aliases

Created on 15 Dec 2017  路  9Comments  路  Source: FriendsOfSymfony/FOSUserBundle

Symfony FOSUserBundle versions:

$ composer info friendsofsymfony/user-bundle
name     : friendsofsymfony/user-bundle
descrip. : Symfony FOSUserBundle
keywords : User management
versions : * v1.3.7
type     : symfony-bundle
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
source   : [git] https://github.com/FriendsOfSymfony/FOSUserBundle.git 113cc4e48fac19d20fc039cfecae9b41103be706
dist     : [zip] https://api.github.com/repos/FriendsOfSymfony/FOSUserBundle/zipball/113cc4e48fac19d20fc039cfecae9b41103be706 113cc4e48fac19d20fc039cfecae9b41103be706
names    : friendsofsymfony/user-bundle

autoload
psr-0
FOS\UserBundle => .

requires
php >=5.3.2
symfony/framework-bundle ~2.3
symfony/security-bundle ~2.3

requires (dev)
doctrine/doctrine-bundle ~1.3
swiftmailer/swiftmailer ~4.3|~5
symfony/validator ~2.3
symfony/yaml ~2.3
twig/twig ~1.5
willdurand/propel-typehintable-behavior ~1.0

suggests
willdurand/propel-typehintable-behavior Needed when using the propel implementation

Description of the problem including expected versus actual behavior:

Steps to reproduce:

These emails of FOSUserBundle are perceived as different, and the mail server as one email.

Gmail

Domain alias

  • @googlemail.com
  • @gmail.com

Email alias

Yandex

Domain alias

  • @yandex.ru
  • @yandex.ua
  • @yandex.by
  • @yandex.kz
  • @yandex.com
  • @ya.ru

Email alias

Mail.ru

Email alias

Most helpful comment

Anyway, I don't think FOSUserBundle should force such rule on everyone. And this could be implemented as a dedicated bundle providing a symfony validation constraint easily.

And if you want to do this in the canonicalizer, that's also an option (which is why FOSUserBundle exposes it as an extension point btw)

All 9 comments

I suggest you to build dedicated validation constraint for that. Shipping them directly in the bundle would be quite hard to maintain (as it requires maintaining rules for each email provider).

People using the bundle might then add the constraint on their user class.

I agree. Putting the problem on others is always easier.
I would add this to the Canonicalizer, not the validator.
It will be better validate a temporary emails.

In any case, it would be worthwhile to mention somewhere about this.

@peter-gribanov Why should aliases not be allowed? Are you going to forbid [email protected] and [email protected] because they are often aliases? What about [email protected] and [email protected]? And [email protected] and [email protected]?

It seems like a crazy idea with no benefit whatsoever. They are syntactically distinct and correct email addresses. The fact that they are all aliases is an implementation detail you cannot be expected to know. Or are you also going to do a background check on anyone who signs up, checking if they have any other email accounts?

@toothbrush7777777 I'm not talking about private domains, but about public services that provide email hosting.

Email [email protected] and [email protected] can be synonymous and may not be synonymous. We do not know this.
But we know for sure that [email protected] and [email protected] are synonyms.
If you do not spill synonyms, then it creates the ability to create an unlimited number of users with only one account.

For example, if we have email [email protected], we can 褋reate an account with emails:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
...
[email protected]

Such accounts can be used for spam, phishing, flooding, cheating, etc.
It can be difficult to clean the consequences of such attacks.

Anyway, I don't think FOSUserBundle should force such rule on everyone. And this could be implemented as a dedicated bundle providing a symfony validation constraint easily.

And if you want to do this in the canonicalizer, that's also an option (which is why FOSUserBundle exposes it as an extension point btw)

@stof I understood your opinion. I'm not going to challenge him.

As i said:

In any case, it would be worthwhile to mention somewhere about this.

Maybe should mention this in documentation?

@peter-gribanov Sorry, I hope I didn't come across as challenging. My only point was to ask why should you disallow some email addresses? It's true that they could potentially be used for spamming, but it is very easy to create accounts to send spam. It may be true that most people don't use tags in their email addresses, but does that mean you should disallow it? That is like requiring the domain name to end in .com because most people have email addresses on domain names ending in .com (e.g. requiring that their email addresses are in the format [a-z0-9.-]+@[a-z-]+\.com).

It may be true that most people don't use tags in their email addresses, but does that mean you should disallow it?

@toothbrush7777777 I don't propose to prohibit the use of tags. I propose to prohibit the use of different tags for one account.

In terms of FOSUserBundle. If email field is equile [email protected] then email_canonical field shold be equile [email protected].

I know use cases where you might need to use tags when registering, but i don't know any normal reason to use a many tags when registering on one site. If you know of such use cases, please tell me about them.

@peter-gribanov I thought you were talking about _banning_ email addresses with tags. I don't necessarily have any use cases for multiple accounts changing only the tag. If I wanted multiple accounts, and the tags were all counted the same, then I would create multiple email addresses.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

suhasini1212 picture suhasini1212  路  5Comments

sinner picture sinner  路  3Comments

karimdev picture karimdev  路  4Comments

Toumm picture Toumm  路  3Comments

tinntsea picture tinntsea  路  5Comments