Jump to content



Recommended Posts

How difficult / easy is it to forge things like $_SERVER['HTTP_REFERER']?


I have a script that allows a user to change their password, and I want to find out if relying on $_SERVER['HTTP_REFERER'] to CONFIRM that a user was sent to the page from only 1 particular page which I have a redirect on is secure enough to be trusted in this manner?


Any input would be appreciated.





Link to comment
Share on other sites

I am using it in combination with a $_GET var. Here is the code I have



$l=explode('/',$_SERVER['HTTP_REFERER']); // grab the referrer & explode it
	$m=count($l)-1; // count the items in the array and subtract 1 to end up with the page name
	$page=$l[$m]; //set the variable for the last item in the array

if(isset($id) && $page=='login.php') // $id comes from a $get var...if that is set and if the referrer
                                                        // page== login.php, proceed.


I am not completely digging this as it seems to open up some possible holes. Can someone suggest a more reliable way of doing this?

Link to comment
Share on other sites

Have this:

$page = $_SERVER['PHP_SELF'];
$_SESSION['page_check'] = $page;

on login.php


and on the process page, have something like this:

if($_SESSION['page_check'] == "login.php") {
   // Proceed
else {
   // Fail - Display an error message

Link to comment
Share on other sites



I was just about to ask about using sessions instead, I hit reply to ask and got that wonderful


"Warning - while you were reading a new reply has been posted. You may wish to review your post" Message.


You answered my question before I even asked it. Thanks.


Sessions are pretty darn difficult to get around right? I am not passing the session id in the url or anything so sessions are "secure" right?


I realize that the next step for *secure* would be SSL, but I don't need to go that route. I can change a few things to make high security not necessary, if need be.



Link to comment
Share on other sites

Sessions are said to be more secure than cookies for one reason -- A cookie is stored on your system, and may be edited by anyone at any time and thus if you have horrible programming skills and use a cookie you can count on someone figuring out how to get into hidden areas of your website by editing the cookie..


a Session -- cannot be edited..  no way no how... 

Link to comment
Share on other sites

Well, I am not worried about wives or kids. Just those who know what the hell they are doing.


The change password form takes a user id that is passed via sessions now (was via $_GET). In the form there are 3 fields. Username, Password, & confirm password. In the user name field, I have it pull the username from a database and display it in a disabled text filed so that the person changing the password can see that it's their username they are modifying.


With the $_GET id pass, a person could theoretically enter random numbers and collect the usernames that were displayed, so you can see why I want something that would take work to get around. What I am protecting is not top-secret types of documents, but I just wanted to add a layer of security so that people don't get their login credentials hijacked.


Sessions are how I am doing it.


Thanks for the help folks.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.