Suggest to prevent using internet valid domain names as default user’s email

[SajjadPourali]

Would you mind if we add the following threat as new verification item?
https://medium.com/@SajjadPourali/do-not-use-internet-valid-domain-names-as-default-users-email-e-g-host-change-me-309213dffb8a

[tghosth]

I think this is an interesting point. Please can you prepare a draft requirement bearing in mind we try to create "positive" requirements,

[SajjadPourali]

Since the description must be clear and should not have any conflict with email registration services, in my opinion, the following requirement is sufficient.

Verify that if the application automatically fills the email inputs, it only suggests the email addresses with the ".invalid" extension.

According to rfc2606, only the ".invalid" extension is an appropriate candidate.

[tghosth]

Ok so maybe:

Verify that where an application automatically provides a default value for email, it uses an email address value with a ".invalid" extension to avoid a collision with a valid email address.

Nice use of RFC :)

Where should this go in the ASVS?

[jmanico]

I think we should add this to a email validation email requirement which deserves some extra treatment, assign this to me? - Jim

On 5/18/20 3:58 PM, Josh Grossman wrote: Ok so maybe: Verify that where an application automatically provides a default value for email, it uses an email address value with a ".invalid" extension to avoid a collision with a valid email address. Nice use of RFC :) Where should this go in the ASVS? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#719 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCN7VNEHVDXY2IWTUI3RSGHNLANCNFSM4KZHO4UQ>.

-- Jim Manico Manicode Security https://www.manicode.com

[vanderaj]

This is a new requirement and thus is a 4.1 issue, not a 4.0.2 bug fix

[jmanico]

Hey @SajjadPourali we are ready for a PR on this one!

[SajjadPourali]

Hey @SajjadPourali we are ready for a PR on this one!

Absolutely

[elarlang]

Never met this problem in my life. Is it worth requirement in ASVS?

[SajjadPourali]

Never met this problem in my life. Is it worth requirement in ASVS?

It's not frequent, but I was facing more than five times with different domain names, including changeme.ir.
In my opinion, it worth. take a search at haveibeenpwned.com and github with "[email protected]" and "[email protected]".

[jmanico]

I am a bit skeptical of this requirement as well @elarlang - it seems very esoteric.

[elarlang]

It's interesting and worth to be in testing guide etc, but if examples are "[email protected]" then it actually means that nothing depends on those values.
Personally I can not see any reason, why email should/can have some default value. To avoid incorrect values, the requirement should be "Verify that e-mail fields does not have default value filled" or something like that.
If e-mail is/can be used for authentication (or for password recovery), e-mail must be verified - which avoid need to proposed requirement.

[SajjadPourali]

It's interesting and worth to be in testing guide etc, but if examples are "[email protected]" then it actually means that nothing depends on those values.
Personally I can not see any reason, why email should/can have some default value. To avoid incorrect values, the requirement should be "Verify that e-mail fields does not have default value filled" or something like that.
If e-mail is/can be used for authentication (or for password recovery), e-mail must be verified - which avoid need to proposed requirement.

I agree with your statement. From my point of view, temporary situations are the reasons that someone uses the default value.
For example: in the development process, developers might don't know about the application owner's mail and set a default value, such as the DNN case, which I have already mentioned in my blog; or sysadmins mistakes.

IMO it's better to change something like this: Prevent users' login until email verification If e-mail is/can be used for authentication or for password recovery, unless domain extension be ".invalid".

[danielcuthbert]

We've added a requirement of validating e-mail addresses based upon your suggestions. This has been added to 5.1.4. If you feel it should go deeper, please re-open this with an example you feel would be suitable.