Default Blog Image

PHP

Tracy R Reed  | 

It has been a while since I did any language trolling so let’s talk about a religious issue: PHP.

PHP - You either love it or you hate it. I have been looking at PHP frameworks lately. Not that I want to but in this particular case there isn’t much choice. I am constantly reminded of all of the reasons why I played with PHP for 6 months then moved away from it so many years ago and have since watched the train wreck from a safe distance.

PHP has no language design philosophy.

With Ruby/Java/Python (almost) everything is an object. Perl has its “There’s more than one way to do it” swiss army chainsaw. Python has “There’s one obviously right way to do it” and zen of python in the “import this” easter egg. Lisp/Haskell/Erlang all have their (purely)functional related philosophies. PHP? Nada.

Not a general purpose language.

Really only meant for webpages. Not a general programming language. While technically you can run php from the command line and automate system tasks with it few people actually use it that way with shell, perl, python preferred instead. I have never downloaded a command line app to find that it is written in PHP. Being able to use the same language for web programming and, say, system automation is a handy way to amortize that learning curve over a number of projects.

Code embedded in HTML is bad

Originally started out as a way to embed basic site counters and such in HTML. It took years but a few people eventually figured out templates were the way to go and started heading towards MVC with templates etc. But far too many people still write PHP intertwined with HTML making a real mess.

Breaks with Apache WebDAV

I set a developer up with WebDAV access to a PHP project so he could edit code, upload files, etc. The very things that WebDAV was designed to do. But whenever he would open up a .php file the editor would come up empty. It turns out that Apache was trying to EXECUTE the PHP file instead of just serving it up for the developer to edit. I found a few references to how to disable the PHP engine when a file is being served up via WebDAV but have so far been unsuccessful in implementing the suggested fix.

Terrible security history

Long a major complaint against PHP and very sensitive subject to PHP programmers. Before flaming me go patch your Wordpress instance. You know it needs it.

The infamous register globals functionality is where people always start when complaining about PHP security. It took years but most people have moved away from using them, especially after it was turned off by default in 4.2. But why did anyone ever think it was a good idea in the first place?

I saw quite a few php apps get owned by the xml-rpc flaw in the 2005-2007 timeframe.

In 2007 it was discovered that you could insert PHP code into a gif name it image.gif.php and get it executed on many sites. Oops. Another instance where parsing your code out of content being served up (instead of separate of logic and presentation via templates) was a big mistake.

I am yet to see anyone religiously use prepared (aka parameterized) statements in PHP to prevent SQL injection which consistently leads to total box ownage. The attackers are generally far more creative than the programmers/admins and find ingenious yet obvious in hindsight ways to pull this off. No, addslashes() is NOT sufficient. mysql_real_escape() is not sufficient either. Take a look at this blog entry from 2007 which sums up some of the more popular options: http://old.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/ Scroll down to where it mentions BIG5 and advanced injection techniques. It is a fact that there is no amount of clever escaping which will suffice. Parameterized queries are the ONLY solution to this problem. Parameterized queries simply makes it impossible to get user input code parsed as part of the SQL statement.

While you can code sql injections in almost any language that speaks SQL to an RDBMS many other languages/frameworks do it differently by default. PHP’s default database interface seems to encourage SQL-injections. The magic quotes hack is just an ugly band-aid. Same for addslashes(). Compare that to Java where you have Command and Parameter objects or can abstract away the SQL generation with Hibernate. Or compare it to Python/Django which also has an ORM which uses parameterized queries. Or to Ruby with its Rails ORM and parameterized queries. Or Zope/Plone with its object database and the inherent impossibility of SQL injection no matter what the programmer does.

And who can forget all of the file inclusion vulnerabilities? Remote file inclusion even! There have even been instances of code injection into PHP regexes via null bytes.

PHP wildly mixes code with strings all over the place causing this mess.

PHPs promiscuous mixing executable code with web content causes trouble as well. 1% of sites accidentally reveal their db passwords: http://www.feross.org/cmsploit/

The latest trend is exploitation of memory corruption bugs in the PHP interpreter itself. You might think that because you are using an interpreted language you don’t have to worry about pointer mishandling, buffer overflows, etc. But it just isn’t so. And PHP has such issues. There are right now undisclosed remote exploits which have not been revealed to the public and have not been patched in the PHP interpreter. There will be a talk on this given at SyScan Singapore 2010.

And then there is the issue demonstrated by this video: http://www.youtube.com/watch?v=6W68u18Bh28&NR;=1 PHP apps traditionally mix static content and PHP code in the same filespace. So if you can get your own PHP code uploaded you can get it executed and suddenly you are owned.

You can say that all of this security attention is due to simply being a very popular language for implementing webapps if you like (although popularity leading to exploits is one of my favorite myths to bust) but it doesn’t change the fact that there are a lot of problems which either don’t exist or are simply less likely to be exploited in other languages/frameworks.

Be sure to keep an eye on http://php-security.org at least to know what you are up against.

PHP is almost everyone’s first web programming language

This may hurt the feelings of a lot of PHP programmers whose business cards say “Software Engineer” but it is an important part of the argument.

Far too many people pick up a PHP tutorial, start coding knowing nothing about software development best practices or security issues, and turn loose some code on the net. This has nothing to do with the language necessarily but a lot to do with the community surrounding it. They are typically either newbies or at the very least not nearly as wise as they think they are.

If PHP is the only web programming language you have much experience with you have a problem.

ReST? MVC? Unit tests? What are those? I know that there are a few PHP programmers out there who practice these things but I have never met one personally.

Too many people start with PHP but then never graduate to any of the other languages/frameworks.