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.
About Me
- ryan
- Information Security enthusiast looking for an entry level position in the field. Hard worker, Quick learner.
PageLock
HTML + Javascript Packer.
2 comments:
When it comes to web-programmers, I think they should learn some fundemental points about secure coding. A short manual about secure coding is enough for a php or asp.net web developer (sql-injection, XSS, ...) - [just consider C]. I think working on php codes by a security professional like you and securing it is wasting time because the prevention requires a little effort.
I'm with you on this one Araz. Implementing code and then having it looked at is not the most effective stance for security. Educating users on security is a far stronger defense. However, this raises an interesting question.
The friend I'm talking about DID implement input sanitizing to defend against xss and sql-injection. In my opinion, attack techniques are not the 'security fundamentals' we should be educating users on. Best practice fundamentals and more generic security principles IMHO are a more important lesson for web developers. If we get them thinking security, they'll learn the basic defenses on their own... hopefully.
Post a Comment