email validation: just enough to prevent sql injection

Discussion in 'Javascript' started by e_matthes@hotmail.com, Oct 28, 2006.

  1. Guest

    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.
     
    , Oct 28, 2006
    #1
    1. Advertising

  2. 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
     
    Peter Michaux, Oct 28, 2006
    #2
    1. Advertising

  3. Lee Guest

    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.


    --
     
    Lee, Oct 28, 2006
    #3
  4. James Black Guest

    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. :)
     
    James Black, Oct 28, 2006
    #4
  5. Guest

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

    Eric
     
    , Oct 29, 2006
    #5
  6. 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
     
    Michael Winter, Oct 29, 2006
    #6
  7. 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)
     
    TheBagbournes, Oct 29, 2006
    #7
  8. Guest

    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
     
    , Oct 29, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?c3M=?=

    sample validation code for sql injection attact

    =?Utf-8?B?c3M=?=, May 5, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    647
    =?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
    May 9, 2006
  2. S N

    Prevent SQL injection error

    S N, May 1, 2009, in forum: ASP General
    Replies:
    3
    Views:
    174
    Bob Barrows
    May 2, 2009
  3. Steve
    Replies:
    4
    Views:
    397
    James Willmore
    Nov 28, 2003
  4. Replies:
    12
    Views:
    320
  5. howa
    Replies:
    2
    Views:
    134
    Joost Diepenmaat
    Feb 25, 2008
Loading...

Share This Page