Re: http referer: guaranteeing that my $variable's content is my content...
| From: | (Richard Lynch) | Date: | Fri, 09 Jun 2000 21:02:38 +0000 |
| Subject: | Re: http referer: guaranteeing that my $variable's content is my content... | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-1443@lists.php.net to get a copy of this message | ||
In article <39401AA0.D4AA2BD@driver8.org>, callen@driver8.org (callen) wrote:
> How insecure/secure is seting a variable on one page ($mustbe=1) to goto
> another page
> and then checking to make sure on the other page that both $mustbe is 1
> and that $HTTP_REFER
> is set also?
Even Joe Sixpack and Betsy Buick can read the URLs in a GET request and
try changing them for fun and profit...
POST is nominally more secure in that they have to read HTML source, more
or less understand it, and edit it...
> Can both of these vars be easily spoofed? Am I correct in assuming that
> my whole host(or DNS) would need to be spoofed in order for the
> HTTP_REFER to be corrupt? If so, any way around this besides querys to
> DB's and cookies?
You are incorrect. Spoofing HTTP_REFERER is only one tiny step higher
than spoofing the POST or GET data.
Cookies are spoofable -- they're just text files on the user's machine
they can edit.
All of these are useful for people who you more or less trust not to try
to mess up on purpose: Malicious users will have a field day if that's
all you're using to stop them.
What you need to do is this:
Put something in there that they won't be able to determine another valid
input from. IE, some sort of encrypted (see crypt() function) data that
they can't then say, "Oh, let's try 2 instead of 1" It's hard to know
what to try when your cookie is CHaeRSDQU2kKL1MIoP
You also store the page they were just on as encrypted data if it's
important to you.
--
Richard Lynch | If this was worth $$$ to you, buy a CD
US Customer Support Director | from one of the artists listed here:
Zend Technologies USA | http://www.L-I-E.com/artists.htm
http://www.zend.com | (this has nothing to do with Zend,
duh!)