identifying a page to be the true one.

[ajoo]

Hi all !

 

I would have liked to continue this question on my previous post but since it became too long I thought I'ld post a new one. 

 

I would like to add the following bit of code on my reset page 

        $current = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
        if(isset($_SERVER['HTTP_REFERER'])) $referrer = $_SERVER['HTTP_REFERER'];
        if ( $referrer === $current )
        {

        }else {

        }

to ensure that the page is being called from where it should be called. Is this OK or is there a better ( read more secure ) way to do it? (I think I read in one of the posts, quite some time ago, that this was not altogether secure). 

 

Since the password reset page is publicly accessible what other security concerns can turn up because of that and what care should be taken.

 

Thanks all ! 

[Jacques1]

I'm not sure what you're trying to do.

 

Which reset page is this about? The page where users enter their e-mail address to request a reset link? Or the page where people actually reset their password after they've clicked on the link? Either way: Which specific threat are you worried about?

 

The Referer header is not reliable. In many cases it's not sent at all, be it because the user suppresses it for privacy reasons, be it because the URL has been entered directly (which should be perfectly fine). And of course the user can set their headers to any value they want.

[ajoo]

Hi Guru Jacques, 

 

Thanks for the reply.

 

I must be getting paranoid about security. Now that you mention it and I am thinking about it I am not so sure which threat I am worried about. I think I had in mind someone impersonating the pages related to password resetting, be it the password email request page or the page in response to that request. Since these pages are public and can be accessed directly I was getting a bit worried.  

 

If that's OK so long as the form and fields authentication / validation is good and if you think there is nothing else that needs to be looked into then I am good. 

Thanks.

[Jacques1]

What do you mean by “impersonating”? Phishing? This cannot be fixed with code, because phishing attacks happen outside of your application.

 

However, you can do something about other attacks:

• The entire site including the reset pages should be delivered over HTTPS so that e-mail addresses and passwords cannot be intercepted.
• Use a CAPTCHA on the request page so that an attacker cannot automatically make you send a large amount of e-mails to an arbitrary address.
• Make sure the request page doesn't reveal if an address is registered or not. Either ask for the public username instead of the e-mail address. Or send out an e-mail for any address (if it's not registered, simply say that in the e-mail itself).
•  

[ajoo]

Thanks Guru Jacques for that insight on other security areas.

 

I would like to clarify if it would be OK to have the captcha ON from the very beginning on these pages since we do not want the user to know if the given email ID is registered or not. I mean we don;t wait for n number of false tries before the captcha is displayed, we use it for every request.

 

Thank you.

[Jacques1]

Yes, do use a CAPTCHA at all times.