joseph-mudloff / pixie-cms

Automatically exported from code.google.com/p/pixie-cms
Other
0 stars 0 forks source link

Insecure use of extract() #7

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The use of extract($_REQUEST) is highly insecure. An attacker can 
overwrite arbitrary superglobals like $_SERVER/$_FILES. Even the manual 
page has a warning: "Do not use extract() on untrusted data, like user 
input"

You could avoid this problem by prefixing all input:

extract($_REQUEST, EXTR_PREFIX_ALL, 'r_');

I haven't used Pixie, was justing checking out the source...

Original issue reported on code.google.com by mrclay....@gmail.com on 5 Oct 2009 at 12:02

GoogleCodeExporter commented 8 years ago
Hi Steve, Thanks for the report. A very helpful and informative suggestion. 
I've 
patched this in svn and used a combination of your recommendation and another 
method 
found in the php manual on the php web site.

Using your prefix method, we still need to check the data afterwards but it 
does 
prevent any variables in the $_REQUEST array from being overwritten.

Work on this is still on-going. Thank you for bringing it to our attention.

Original comment by tonywhit...@googlemail.com on 21 Jan 2010 at 5:33

GoogleCodeExporter commented 8 years ago
Further to this, I actually patched this myself for people who can turn on 
clean 
urls by uploading a strong .htaccess that includes :

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#

In the mod_rewrite section, without even realising it. So the flaw is pretty 
much 
patched for users of the extra .htaccess available from the addons section 
Pixie 
website.
That .htaccess is in svn now and built into the installer, so step one complete.
Flaw patched for Pixie users that can use clean urls.
There is also now a level of protection for users without clean urls turned on.

I think we can close this now.

Original comment by tonywhit...@googlemail.com on 22 Jan 2010 at 1:44

GoogleCodeExporter commented 8 years ago

Original comment by tonywhit...@googlemail.com on 22 Jan 2010 at 1:45