Login Email JQuery Validation

[lindasdd]

I'm playing with the Jquery Validation Plugin: http://jqueryvalidation.org/ in an attempt to validate the email_address field on the login page prior to hitting the submit button (so customers having login troubles can tell if it is their email address that is incorrect).

What the page should do: as soon as someone enters a value in the email_address field, the jquery loads a php file that contains a sql call to see if the email address exists in the database and returns a message based on the results.

I'm stuck on the sql portion. At this point I have gone as far as removing all variable from the process until I can get the basic sql to return a result.

<?php
 
/* check if email is already registered */
 
if (!empty($_POST['email']))
{
    global $db;
    $sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = 'atestemail######################' LIMIT 1";
    $result = $db->Execute($sql);
    if($result->RecordCount()>0)
    
    {
        echo "true";  //good to register
    }
    else
    {
        echo "false"; //already registered
    }
}
else
{
    echo "false"; //invalid post var
}
 
?>

[rbarbour]

Try replacing

$getUserEmail = $_POST['email'];

$sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = '" . $getUserEmail . "' LIMIT 1";

Hope this helps!

However most jQuery/AJAX uses the $_REQUEST method to obtain information from a form.

I'm playing with the Jquery Validation Plugin: http://jqueryvalidation.org/ in an attempt to validate the email_address field on the login page prior to hitting the submit button (so customers having login troubles can tell if it is their email address that is incorrect).

What the page should do: as soon as someone enters a value in the email_address field, the jquery loads a php file that contains a sql call to see if the email address exists in the database and returns a message based on the results.

I'm stuck on the sql portion. At this point I have gone as far as removing all variable from the process until I can get the basic sql to return a result.

<?php
 
/* check if email is already registered */
 
if (!empty($_POST['email']))
{
    global $db;
    $sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = 'atestemail######################' LIMIT 1";
    $result = $db->Execute($sql);
    if($result->RecordCount()>0)
    
    {
        echo "true";  //good to register
    }
    else
    {
        echo "false"; //already registered
    }
}
else
{
    echo "false"; //invalid post var
}
 
?>

[DrByte]

Try replacing

$getUserEmail = $_POST['email'];

$sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = '" . $getUserEmail . "' LIMIT 1";

Hope this helps!

However most jQuery/AJAX uses the $_REQUEST method to obtain information from a form.

Oy! That's a SQL Injection disaster waiting to blow up your entire site!
Never use $_POST or $_REQUEST or $_GET etc data directly in an SQL query without sanitizing it first!!!!!!!!!
Something like this is safer:

$sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = :email LIMIT 1";
$sql = $db->bindVars($sql, ':email', $_POST['email'], 'string');

And your script needs to first run application_top in order to get access to the database via $db.

[mc12345678]

If this is pulling data from the database as far as being an email address that is in the database as compared to properly formatted (ie. Two @ symbols or a space in the address) isn't this just weakening the security of the system?

If I enter an address that clearly does not exist in the database the, I get one response, if I enter an email address that is in the database then a different response. If that is the case, then I need only test passwords after obtaining enough information to know what email addresses are contained, or even absent of that, I can test to see what email addresses exist and then use that information to send emails to those individuals outside of the site that is using this tool...

[rbarbour]

Very true,

Sometimes my fingers are faster than my brain

Oy! That's a SQL Injection disaster waiting to blow up your entire site!
Never use $_POST or $_REQUEST or $_GET etc data directly in an SQL query without sanitizing it first!!!!!!!!!
Something like this is safer:

$sql = "SELECT customers_id FROM zen_customers WHERE customers_email_address = :email LIMIT 1";
$sql = $db->bindVars($sql, ':email', $_POST['email'], 'string');

And your script needs to first run application_top in order to get access to the database via $db.

[DrByte]

If this is pulling data from the database as far as being an email address that is in the database as compared to properly formatted (ie. Two @ symbols or a space in the address) isn't this just weakening the security of the system?

If I enter an address that clearly does not exist in the database the, I get one response, if I enter an email address that is in the database then a different response. If that is the case, then I need only test passwords after obtaining enough information to know what email addresses are contained, or even absent of that, I can test to see what email addresses exist and then use that information to send emails to those individuals outside of the site that is using this tool...

True. Such a script should not be used to tell the end-user anything more than valid/invalid. And "already exists" should be lumped in with "invalid", when attempting to sign up for an account. When doing a "please send me my password" request, no response should be provided other than "if a match is found an email will be dispatched", not "sorry we couldn't find that in our database". Disclosing too much useful information empowers hackers with information that targets their attacks, thus making your site more vulnerable to malicious activity.

[acerldd]

The potential security risk for someone with a dedicated script to keep trying emails and then passwords has been on my mind.

But, my database doesn't hold any payment information so even if you are able to log in to someone else's account you aren't able to access their payment info or even place an order under their details.

Or is there a different security risk I'm not considering?

[acerldd]

And your script needs to first run application_top in order to get access to the database via $db.

I think this was all I actually needed. Got it to work now.

[mc12345678]

The potential security risk for someone with a dedicated script to keep trying emails and then passwords has been on my mind.

But, my database doesn't hold any payment information so even if you are able to log in to someone else's account you aren't able to access their payment info or even place an order under their details.

Or is there a different security risk I'm not considering?

While you won't notice it on your version of ZC, version 1.5.3+ places the login/create account screen as a secure connection. Is it just because. Eventually some payment information may be collected? I would like to think it is more than that as personal information is collected about the individual. Some to support purchase completion, others as considered necessary by the site owner/developer.

While perhaps your site may not hold anything other than an email address and a matching password (no name, no addresses, no birthday, etc...), in what might be distribution of the associated code should do best to identify the known hazards and concerns...

Another way to look at it: so, yes trying to do something to help the unfortunate who are not sure about having entered the right information, but should also look at it as, is there any reason anyone other than the single individual should see the response/result? In most cases, the answer is no, there is no reason others should be able to tell anything about an entered email other than it is formatted such that no email system could properly handle it.

Now, in a sort of paired effort, if the check of email address were internally logged and when a customer indicated having difficulty with login or upon routine review of those logs it was identified as a problem, then well, talking an entirely different matter. At that point the data is only internally kept and access to the admin area/files is controlled correct?

Kind of wondering though why there is such a need for this extra verification? Is there something about the target market where login is an issue? Is it/has it been a ploy to gain improper access? Have the inquiries gotten to such a level that it is not manageable? It's just one of those things where it may serve to understand and maybe prevent the need for this type of thing instead of reacting to it... Dunno. :) happy holidays regardless.

[acerldd]

Kind of wondering though why there is such a need for this extra verification? Is there something about the target market where login is an issue? Is it/has it been a ploy to gain improper access? Have the inquiries gotten to such a level that it is not manageable? It's just one of those things where it may serve to understand and maybe prevent the need for this type of thing instead of reacting to it... Dunno. :) happy holidays regardless.

It has not become burdensome to handle as an admin, but any hiccup that causes delays in logging in causes customer frustration and eats up admin time. Every little fix that can be put in place helps.

As well, normally the type of customer who this would help is the same type of customer who angrily emails/calls claiming our website is broken when really they just are entering their email address incorrectly.

Based on this thread though, I'll just stick with general format validation.