A friend asked me to have a look at some php he was working on yesturday and I found a few interesting little security weaknesses I'd like to discuss.
First of all, maybe someone could help me out here, I'm not sure why this practice caught on. A lot of modular php projects use the file extension '.inc' for external modules, rather than '.php'. This is problematic. If a .inc is called directly, it wont be processed by the php interpereter so the code will be sent to the client rather than the expected output. Some will undoubtedly argue that these .inc modules are hidden to endusers and therefore will never be seen. This is a classic case of security through obscurity, and a very BAD stance. Here is and example of why:
.inc Google Dork. <- this is a google search for every .inc file containing mysql_connect. You might be surprised to see how many sql usernames/passwords show up.
Robust security is hardening, not hiding.
The other weakness I found sort of made me smirk. This is a good example of why secure code will only allow good input, rather than disallowing bad input. My friend was reusing some old code he had written to allow a user to upload files. He had a list of extensions that users were not allowed to upload. These included: php, php2, php3, php4, phtml. When the code was written .php5 was not a valid extension but since then, he had updated to php 5. I simply wrote a php passthru() shell and uploaded it as x.php5. This is classic. When a developer allows the environment to take care of security, rather than building security into the app he's developing. The same thing happens when a developer trusts php settings like magic quotes or register globals to take care of security. If the application is migrated, or the configuration is changed, the code might become a gaping hole.
The point I'm trying to make is, write secure code. Don't trust your environment to be secure.