Is this a good security measure?

[hadoob024]

This isn't all the security checking that I'm doing, but I thought that it might be useful. Let me know what everyone thinks.

I was thinking of creating an array that contains all of the PHP pages that I have (well, the ones accessible by the browser and not just includes and such). And then at the beginning of every file, I wanted to check and see whether or not we came from one of the files listed in the array. If not, then do a re-direct on them to index.php or something similar to this. And I was thinking of checking the values by accessing the values stored in something like $SERVER['HTTP_REFERER'] or maybe $SERVER['REQUEST_URI'].

Also, more specifically, if someone tries to access a page that processes a form, I want to check and make sure that they only got to that page by accessing the page that contains the actual form. If not, re-direct them to the page with the form on it.

So, any thoughts on this?

[bbreslauer]

I like the second part; it would be useful with the processing of forms.

The first part would be annoying to keep up-to-date, as you'd need to update it every time you add a new page. Without doing all of that, and still keeping the same basic security measure in place, you could just check the http_referer variable and see whether it came from your website. I'm pretty sure there's no less security doing this than there is by seeing if they came from a page that's in the array.

[MarkR]

No, it's terrible. This is because some browsers can be configured not to send HTTP_REFERER, and/or some hardware or software firewalls remove it from the request.

Moreover, it's not even particularly secure. However, some CSRF exploits might be preventable by this method, theoretically.

A better way, is to create some unique ID per user, and store that in a hidden field in the form, then when the POST arrives, check this value is correct, and throw an error if it isn't.

That would stop CSRF.

Mark

[hadoob024]

Yeah. I've already planned on implementing a token to check whether a person arrived at the form receiving page, by actually going through the form page. Something like:

session_start();
$secret = md5(uniqid(mt_rand(), true));
$_SESSION['secret'] = $secret;
<input type="hidden" name="secret" value="<?php echo $secret; ?>" />

and then doing a check on this on the form receiving page:

if (($_SESSION['secret'] != $_POST['secret']) || (!isset($_SESSION['secret'])))
{
     //do the echo's/redirect's here.  Call error handling function
}
else
{
     //unset() session variable
}

But I was just thinking in terms of an additional security measure. Would it be helpful at all? Or would it cause problems if HTTP_REFERRER is not being sent? It seems that if it's not sent, then people wouldn't be able to access any other page on my site other than the main page, as they would keep getting re-directed, right?

What about $_SERVER['REQUEST_URI']? Is it any better than using HTTP_REFERRER?

[MarkR]

Using this session variable in a hidden field would be good.

However, you don't need to keep it in a session variable; a cookie would do, because an attacker could never obtain the user's cookie anyway (plus, it should be a session cookie)

Mark

[hadoob024]

I was thinking about that. But don't users have the option of not accepting cookies? And in that case, they would never get validated, right? That's why I just wanted to implement it the way I have it.

Oh, and any thought about $_SERVER['REQUEST_URI']? Is it any better than using HTTP_REFERRER?

[MarkR]

REQUEST_URI will give you the same as SCRIPT_NAME, I believe.

It won't help you protect against CSRF and it just gives you the URI of the current script (possibly including path info, query string?), not the previous page. So it won't help defend against CSRF.

To prevent CSRF, you need something coming from the previous page, typically in a hidden field, that another user could not guess or compute (hence they can't put it in their own form somewhere else) - such as a unique ID, or something.

It need not use cookies - you could use HTTP authentication and have per-user secret CSRF-prevention code.

Referrer checking might be somewhat effective against CSRF, but you can't assume that no referrer indicates a CSRF attempt - it's more likely that a legit user has referrers blocked, in which case you won't be able to detect it.

Mark

[hadoob024]

Well, I guess I wasn't really planning on using this to protect against CSRF. It was more to maintain control of the site. Like I don't want anyone to access my PHP files which are nothing more than lists of functions, and I don't want anyone to directly access a form receiving page. The PHP function stuff I handled by putting these files in a directory outside of the web document root. However, I can't really do something similar with a form receiving page.

How do you handle this situation? What does everyone else do to make sure that a user can't directly access a page that processes a form, and instead has to access the form page directly?

Also, could you explain what you mean by "It need not use cookies - you could use HTTP authentication and have per-user secret CSRF-prevention code."? I read that over a couple of times and wasn't sure what it meant. Are you talking about implementing something like what I was talking about with:

session_start();
$secret = md5(uniqid(mt_rand(), true));
$_SESSION['secret'] = $secret;
<input type="hidden" name="secret" value="<?php echo $secret; ?>" />

[MarkR]

hadoob024 wrote:

How do you handle this situation? What does everyone else do to make sure that a user can't directly access a page that processes a form, and instead has to access the form page directly?

I take no special measures to do so.

Seeing as we usually have pages post to themselves, the page will display the form if it's accessed via a GET, and process the form if a POST is done with the correct values.

The reason we do this is simple - so that in the event of a validation error, we can re-show the form with the previous values filled in.

If the user goes directly to the page - they just see the form. Which is what they'd see anyway.

If the user maliciously constructs a POST, they'll just end up with the form with some values filled in and some validation errors, because all data submitted are subject to rigorous checks (never trust the web browser).

Also, could you explain what you mean by "It need not use cookies - you could use HTTP authentication and have per-user secret CSRF-prevention code."?

If you use HTTP authentication, you can determine who a user is without using cookies. The browser will keep the HTTP authentication data for the session, even when cookies are disabled.

Because you know who the user is, you can keep secret per-user information and look it up. This could be used in a CSRF-prevention.

I think that you should read up about CSRF, as I suspect you don't know what it is.

There is a page explaining it here: http://www.petefreitag.com/item/348.cfm

Mark

[hadoob024]

I think I got the hang of it. I do screen everything, I mean EVERYTHING. I perform a trim(), then a strip_tags(), then I manually strip out various characters like ; = \ etc. Then after this I run each of the inputs through an eregi().

Regarding the single page structure. I set mine up with two, form page and form processing page. Thus if there is an error, I tell the user to use the 'Back' button on the browser (which maintains the form info), or I supply a link like so (which also maintains the form info):

echo '<FORM><INPUT TYPE="button" VALUE="Back" onClick="history.go(-1);return true;"></FORM>';

As for the CSRF stuff, I think I've done some stuff to help. I don't use GET, only use POST. I have register_globals turned off, and don't access the variables directly, but screen/sanitize them before setting them. What else, oh yeah, I thought my session token implementation would force the use of my own forms and not allow someone to try and submit a form submission that doesn't come from my actual form page (although I'm guessing that using this would negate the need to use HTTP_REFERRERS to see whether or not they got to the form receiving page via the form page, right?).

I don't really have any sections of my site that are only for authorized users. I basically have a website that lists real estate. Anyone can do searches for free (there is no membership or authentication required), and then to add a listing, I only have to work in charging the user a dollar amount to list his/her property on our site. And to the 'add listing' section, I'm adding a timeout feature that gives the user something like 10 minutes to fill out the form otherwise the form's rejected.

Thanks for the website though. I think I'm prepared against what they say to look out for, but I'm all about reinforcing these principles.