Yeah this is kind'a old if you have been developing sites for a
while, you also need to consider that someone can also do this off the
site as well. So if they have the ability to link to a site from your
site they can get people to go to that site and then do the post from that
site and this defeats this protection. Therefore, although, everyone disparages
HTTP_REFERER checking, in this case it will protect the innocent user.
For critical areas you could also force the user to enter their
password or something similar which will also prevent this attack from
working.
You also need to filter out javascript if you allow the user to
craft their own image tags, this is a much worse problem becasue they can
then claim the users cookie, encryption won't help you here. Of course
they could also do other bad things with javascript. ( It has been pointed
out to me that most tools out there already filter, I am just trying to be
complete, there may be some following the discussion that this is not
clear to )
As well if you do encypt cookies and you use lets say Mcrypt_CFB
be careful, if data items fall within a block they can twiddle bits and
corrupt data, in that block while leaving other blocks intact so I would
advise attaching a HASH of all the data in the cookie at the end, so if
you use a good HASH like MD5 it should be impossible for them to corrupt
cookie without you knowing, if you check.
I had at one point thought it would be useful to use IPs to verify
users identity but AOL proxies do not maintain IP Addresses so a users IP
can change rapidly as well they vary over the whole 2 last octets of the
IP so you can't even validate that they come from the same C class
network. AOL is far from the only one that does this, I have even seen a
users IP vary over different A class networks, IIRC they where from
Sympatico.
Take care
Wed, 13 Jun 2001, John Percival wrote:
> How can it be fixed? Well, there are a couple of ways to stop it, but the
> easiest (in PHP at least) seems to be to have most of the variables used by
> scripts be used through $HTTP_POST_VARS. So instead of checking for $action
> in a script, $HTTP_POST_VARS['action'] would be checked. This forces the
> user to use a POST request, not a GET. Alternatively, the sessionid could be
> required to come with the GET/POST request variables, rather than by cookie.
> Finally, in the specific case of [img] tags, the use of ? or & in the img
> URL can be disabled by some regexes.
==========================================================================
--"the more you know and understand the more you must know and understand
.. knowledge is an unsatiable hunger .. which makes life easier and at
the same time harder .... knowledge is a paradox w/ no resolution just
a boundless function of human nature .... knowledge is a trap which we
embrace and which we run away from .... and in the end the only escape
is death .... or maybe not "<grin>--
==========================================================================
-This message transmitted on 100% recycled electrons-
-Save the whales, Feed the hungry, Free the mallocs-
Two cats on a roof,
Which one falls off first?
The one with the smaller mew.
This archive was generated by hypermail 2b30 : Fri Jun 15 2001 - 12:52:06 PDT