«

Hello everyone,

I've read enough about email validation to know that the only real
validation is having a user respond to a confirmation message you've
sent them. However, I want to store the address temporarily, so I want
to make sure what is entered is safe to work with. I have a basic
understanding of regexps, so I could write one that checks for a simple
format like: something followed by @ followed by something followed by
.. followed by something. I can also make a good guess at understanding
the regexps I come across in validation schemes people have posted.
However, each scheme that is posted seems to get criticized for
invalidating some esoteric, but valid, addresses.

I'm wondering if there is a minimum validation you can do that will
prevent basic attacks like sql injection attacks. For example, if I
weed out anything with single and double quotes, and semicolons, am I
barring some people unnecessarily? Seems like you'd be trying to mess
with people by putting a semicolon in your email address.

I know there are other steps to take in preventing attacks. Every
layer helps, though, so I'd like to do some reasonable email validation.

wrote:
> Hello everyone,
>
> I've read enough about email validation to know that the only real
> validation is having a user respond to a confirmation message you've
> sent them. However, I want to store the address temporarily, so I want
> to make sure what is entered is safe to work with. I have a basic
> understanding of regexps, so I could write one that checks for a simple
> format like: something followed by @ followed by something followed by
> . followed by something. I can also make a good guess at understanding
> the regexps I come across in validation schemes people have posted.
> However, each scheme that is posted seems to get criticized for
> invalidating some esoteric, but valid, addresses.
>
> I'm wondering if there is a minimum validation you can do that will
> prevent basic attacks like sql injection attacks. For example, if I
> weed out anything with single and double quotes, and semicolons, am I
> barring some people unnecessarily? Seems like you'd be trying to mess
> with people by putting a semicolon in your email address.
>
> I know there are other steps to take in preventing attacks. Every
> layer helps, though, so I'd like to do some reasonable email validation.

You can do this validation in JavaScript but a hacker will know how to
turn JavaScript off or otherwise send data to your server. No matter
what test you decide on, you will have to repeat this test on the
server.

Peter

said:

>I'm wondering if there is a minimum validation you can do that will
>prevent basic attacks like sql injection attacks. For example, if I
>weed out anything with single and double quotes, and semicolons, am I
>barring some people unnecessarily? Seems like you'd be trying to mess
>with people by putting a semicolon in your email address.
>
>I know there are other steps to take in preventing attacks. Every
>layer helps, though, so I'd like to do some reasonable email validation.

"Every layer helps" sounds good, but isn't really true.
Testing for the same violation twice doesn't make you more likely
to catch it. Client-side validation adds nothing at all to
protect you if you also have server-side validation in place.

The only valid purpose for client-side validation is for the
convenience of the user, to let them know immediately if they've
accidentally entered bad data. Having them enter their address
twice is probably good enough for that. If they mistype it wrong
twice, let them wait to find out about their mistake from your
server-side code.

Consider also that the malicious user can look at your client-side
code to see what you have, and have not, thought of, increasing his
chances of defeating your server-side validation.


--

wrote:

> I know there are other steps to take in preventing attacks. Every
> layer helps, though, so I'd like to do some reasonable email validation.

Your best bet is to do simple validation on the client-side.

For example, you could limit it to 64 characters. Require that there
is an @ sign.

Then, on the server side, use prepared statements to store the email
address, as that will help protect against sql injection.

If you want to be more paranoid, on the server-side, just randomly
generate a number. Append that to the start of the email address, then
do XOR on the rest of the string, where the first letter (randomly
generated) is XORd with the second, the second with the third, and so
on.

This would help change the string enough to where the attack would
fail, as the hacker has no idea what you use on the server for the XOR.

Good luck.

Thank you! That clarifies my thinking about client-side validation. I
appreciate it.

Eric

wrote:

> I've read enough about email validation to know that the only real
> validation is having a user respond to a confirmation message you've
> sent them.

Yes. A syntactically valid address may not exist.

> However, I want to store the address temporarily, so I want to make
> sure what is entered is safe to work with.

How does validation help with that? A valid e-mail address that, if used
as-is, may play havoc with a SQL statement is still valid. What would
you tell the user? "Sorry, but your e-mail address would break my
database?" That's hardly reasonable.

What you need to focus on is making a valid address safe, not limiting
what is considered valid. The address will be included in SQL statements
as a quoted literal, yes? So, only other quotes should cause problems
and these can be escaped (two consecutive quotes, or a preceding
backslash, depending on DBMS).

The API for your database client library should include a function that
will escape input such that it won't interfere with an SQL statement.
Some query functions may avoid SQL injection by separating parameters
from the SQL statement itself, thereby preventing values from altering
the structure of that statement. The documentation for your DBMS will
provide more information.

[snip]

Mike

wrote:
> Thank you! That clarifies my thinking about client-side validation. I
> appreciate it.
>
> Eric

You can totally avoid SQL injection by using a PreparedStatement

(If you have the advantage of being able to use Java and JDBC)

I have read about prepared statements and escaping input, but have not
done that coding yet. I'll ask in the appropriate groups if I have
questions when I get to that point. Thanks again everyone, this really
helps to clarify what I should and should not be doing client-side.

Eric