Re: http referer: guaranteeing that my $variable's content is my content...

From: 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!)

« previous php.general (#1443) next »