forgotten password failutre

[jimlongo]

If the email address has a + sign in it, you get an error when trying to reset the password. 

 

 Error: The E-Mail Address was not found in our records, please try again.

 

You will recieve the email in both cases, the url is formed properly, the email address is urlencoded,  but in the second case you get the error I posted.

 

These are the urls I received via email. The first one worked, the second one failed.

https://mydomain.com/password_reset.php?account=myemail%40gmail.com&key=removed      ([email protected])
https://mydomain.com/password_reset.php?account=myemail%2B1%40gmail.com&key=removed  ([email protected])

[MrPhil]

A "+" in a URL is normally taken to mean a literal space (blank). It looks like, even encoded as %2B, someone may be decoding it to "+" too early, and the system is taking it as a space. The email ID is supposed to have a space or a literal plus sign? A literal plus sign in an email might be allowable, as I don't think it gets handled the same way as URLs, but when you try putting that email address in a URL that could get misinterpreted as a space. I'm not sure if the email address could be further encoded in some way (perhaps myemail%252B1). Just some random brain static here before my coffee kicks in...

[jimlongo]

it's meant to be a literal plus sign, an email address like '[email protected]'

 

This is allowable by almost any RFC you can find on email addresses.  Whether every provider allows it is irrelevant.

 

I can't find in the code where it is encoded, or if there is any regex going on anywhere.

[jimlongo]

The query string is urlencoding the email.   

The email is stored in the database as plaintext.

 

I guess we're not url encoding the unencoded answer in the database to match the url encoded address in the query string.

 

In essence '[email protected]' != 'myemail%2B1%40gmail.com' is what the application is finding when we try to login with that url. And that's the error, we couldn't find that email in the database.

 

EDIT: Reading this comment back, this would also imply there should be a problem with the @ symbol as well. So still a mystery in my mind. I'll try to look at the code later.

[MrPhil]

Well, "+" has special meaning beyond just replacing %2B with + at some point. If it's still in a URL at that point, it gets changed to a space. Somewhere in creating that URL, probably urlencode() was called, which converted + to %2B and @ to %40. That's fine for the @, but I suspect that after the %2B is changed back to a +, it then at some point gets changed to a space, which you don't want. It's just a wild guess that after the urlencode() call, you might try changing any %2B to %252B and see if that makes a difference. It's possible it won't help, and then we'll know one more thing that doesn't work. It's also possible that will fix the problem.

[jimlongo]

This is happening in password_reset.php

 

$email_address = tep_db_prepare_input($HTTP_GET_VARS['account']);

in calls tep_db_prepare_input() from includes/functions/database.php

  function tep_db_prepare_input($string) {
    if (is_string($string)) {
      return trim(tep_sanitize_string(stripslashes($string)));
    } elseif (is_array($string)) {
      reset($string);
      while (list($key, $value) = each($string)) {
        $string[$key] = tep_db_prepare_input($value);
      }
      return $string;
    } else {
      return $string;
    }
  }

it calls tep_sanitize_string() from includes/functions/general.php 

function tep_sanitize_string($string) {
    $patterns = array ('/ +/','/[<>]/');
    $replace = array (' ', '_');
    return preg_replace($patterns, $replace, trim($string));
  }

you can see the plus sign is getting replaced by tep_sanitize_string().

 

I'd suggest OSC should use a new function tep_sanitize_email_string() with a different regexp and use that instead.

I'll have to look, never have been good at regex.

[jimlongo]

hmmm . . . that's not what that preg_replace is doing

I think it's replacing multiple spaces with 1 space and replacing gt lt symbol with underscore

I think my theory is still not right . . .

[ecommunlimited]

@@jimlongo

 

This works great for me Admin Change Customer Passwords

 

Take care

Bill

[jimlongo]

Thanks Bill.

 

But I'd prefer customers to be able to reset the password without bothering me.

 

I'd appreciate it If someone could confirm this bug,

I'll keep looking.

[MrPhil]

In /password_forgotten.php, there is a line

       $reset_key_url = tep_href_link('password_reset.php', 'account=' . urlencode($email_address) . '&key=' . $reset_key, 'SSL', false);

I suspect that $email_address at this point is '[email protected]'. After urlencode(), it would be 'myemail%2B1%40gmail.com'. At this point, you could look for '%2B' and replace it by '%252B' and see if that makes any difference. You'd have to pull the urlencode() call out into a separate line, check and update the resulting string, and put it into the tep_href_link() call.

 

I have not tried this, but it's simple and worth trying if you're still stuck. I'm fairly certain that the %2B is being expanded to + too early in the process, and hope that further encoding the % to %25 might delay it long enough that the + isn't expanded to a space.
 

[♥John W]

Interesting thread.  According to http://www.php.net/urlencode spaces are encoded as + signs, so it seems that having a + sign can cause issues. 

[♥John W]

Out of curiousity, I searched through my customer database and only 3 people had a + sign in their email. 

EDit: Actually, 2 were the same person doing it years apart.

[jimlongo]

Oh I know it's pretty academic. I only came across it because I use it in gmail addresses when testing.
 
I think this sounds like the ticket, I'll try it later
7 year old comment in the PHP manual page php.net/manual/en/function.urlencode.php

"Don't use urlencode() or urldecode() if the text includes an email address, as it destroys the "+" character, a perfectly valid email address character. Unless you're certain that you won't be encoding email addresses AND you need the readability provided by the non-standard "+" usage, instead always use use rawurlencode() or rawurldecode().

[jimlongo]

Everything is fine until you submit the form.

It's in the form itself that this occurs (around line 88)

<?php echo tep_draw_form('password_reset', tep_href_link(FILENAME_PASSWORD_RESET, 'account=' . $email_address . '&key=' . $password_key . '&action=process', 'SSL'), 'post', 'onsubmit="return check_form(password_reset);"', true); ?>

urlencode() the email address in the form href link to match the variable

<?php echo tep_draw_form('password_reset', tep_href_link(FILENAME_PASSWORD_RESET, 'account=' . urlencode($email_address) . '&key=' . $password_key . '&action=process', 'SSL'), 'post', 'onsubmit="return check_form(password_reset);"', true); ?>

Tested with the following:

[email protected]

[email protected]

[email protected]