Create Customer Profile requests with emails containing a + symbol return E00013 "email is invalid"

[jantzenw]

Create Customer Profile requests with emails containing a + symbol return E00013 "email is invalid"

Request without error: http://www.screencast.com/t/a5sxNsEn

Request with error: http://www.screencast.com/t/RZPbDcl57S

Request and response without error: https://gist.github.com/jantzenw/cf672ec18b36ac069109dcb452a2d525

Request and response with error: https://gist.github.com/jantzenw/a65636cd78f9757b5eb1222dd63766d5

The first instance of this error was today at 2018-03-29T14:23:40+00:00.

It is critical that the email validation be updated to allow + symbols because this is a valid email character: https://support.google.com/mail/answer/22370?hl=en#alias. This is commonly used in testing to allow multiple accounts to share the same inbox. 

[jantzenw]

Authorize.net support gave this reply: 

'I've reached our to our developers and engineers, since this is a highly unusual question. They have confirmed that our system does not allow that character, and that this is an intentional decision. They provided the following reason as an explanation of why that decision was made:

"It is a security issue. We do not allow the special characters so that hackers cannot do SQL injection in the field"

I'm sorry for any inconvenience, but I hope this information helps.'

[bryankacz]

It seems as this has just changed today with little to no notice for developers.  It has taken down our systems at 3 of our retail locations due to the fact that we utilize the + sign in an email to insure a unique address when creating a customer.

[mfiedel]

This is negatively affecting our ability to QA our staging environment because we use the ability to add a "+" to establish aliases for testing, without needing to create a unique email address everytime.

The lack of communication on this update by Authorize.net is frustrating.

[matth]

We're also having the same issue starting yesterday.

Many of our customer's accounts have a valid + in the email address and the payments are now getting this error when trying to place an order.

[schmich]

This change is unacceptable.

Everything jantzenw mentioned about validation is correct. In addition, see this StackOverflow answer with multiple references to IETF RFCs. "+" is absolutely a valid email address character.

> It is a security issue. We do not allow the special characters so that hackers cannot do SQL injection in the field

I appreciate that there might be Authorize.net internal implementation details I'm unaware of, but this statement in general is misleading and should not be considered a valid reason for rejecting "+". Using SQL prepared statements or any openly available libraries to properly escape queries prevents injection.

As jantzenw mentioned, we also use "+" in emails in development and testing in order to have unique email addresses while still having a shared inbox. Furthermore, it's a common practice for privacy-minded folks to include the site's domain in their email when registering, e.g. "user@gmail.com" becomes "user+domain@gmail.com".

I sincerely hope this change will be reverted.

[RichardH]

Hello @schmich @jantzenw @matth @mfiedel @bryankacz

We've escalated your report to our product team.  We'll post updates to this thread when we receive them. 

Richard

[knightcode]

Just ran into this problem as well..... and I have so many doubts about your development process now. How did no one know the '+' symbol was part of a valid email address? How did no one catch this problem in review? How the hell were you still vulnerable to SQL injection attacks?

Why the **** do you even need a uniqueness constraint on the email field? Who cares what email our system gives yours for a new account. The customer can't log into yours. The ID's the only thing that matters.

[knightcode]

You're also flagging the single quote, presumably for the same SQL injection attack reason, but this, too, is a valid character in an email address.

Reference: https://en.wikipedia.org/wiki/Email_address#Syntax

[Vikas_chauhan]

I am also facing the same issue

can anyone help?