On Jan 17, 2008, at 10:17 , Stefan Esser wrote:
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for
*.co.kr
(in FF atleast).
Ok, you are assuming one security issue here, that is not related to
the topic. So in other words, the topic at hand has the potential of
worsening the impact of an application security flaw.
Then you CANNOT use the application anymore. This is a DOS. You cannot
defeat this problem except detecting and telling the user to delete
his
cookies manually...
There are only hard ways to kill the cookie for you, because then you
would need to
a) parse the cookie header to know exactly how it is called (remember
whitespace in the beginning is ignored)
b) you need to guess for what domain/path combination the injected
cookie was set (because otherwise you cannot kill it)
Have fun with sending tons of Set-Cookie headers or have fun with
telling a DAU how to kill his cookies...
Right, I see the problem. The trickier issue is even figuring out that
such a funky named cookie was set. I doubt many of us would even think
of that. Instead when faced with a DAU customer like that they would
assume its some other end user error.
I do not know enough about the details of how cookies work, but
couldnt there be some way to optionally make the cookie parsing more
strict?
So you see that you nearly NEVER ever want the cookie in _REQUEST. And
even if you can think up a theoretical situation where you don't care
the problem is that everyone else uses _REQUEST in unsafe places...
Therefore my recommendation in PHP source code audits is usually... If
your code uses _REQUEST then overwrite it with an array_merge() of
_GET
and _POST in the beginning of the script.
Never is an exaggeration. I have used this "feature" to make certain
parameters persistent across sessions. However it might be a nice
touch if one could leave out items from the GPC setting and thereby
prevent them to get added to _REQUEST in the first place.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
