Forum Moderators: coopster
PHP is a very popular language with many flawed security "features". Every PHP developer and hoster should understand the primary attack vectors being used by attackers against PHP applications.
From OWASP [owasp.org]
PHP 4.x should not be run in any shared or dedicated environment of any consequence. Hosters should give notice to their clients that they have only a short time to bring their software up to date with PHP 5.x and rapidly adopt the latest version of PHP
Where is the evidence to back up this rather ridiculous statement?
All the supposedly flawed security features this article deals with come down to the same conclusion: if you don't know what you're doing your programs are at risk.
programming in PHP 4.x is perfectly safe, as long as you know what you're doing
This article is the underlying research behind the SANS Top 20 2005's PHP section. The methodology used in the preparation of this article is to review all Bugtraq postings containing the word "PHP" and categorize each unique flaw.
What other security resources do you use besides SANS and Bugtraq? If you find them to be more reliable, please include a link, in accordance with the ToS. I use several, myself, and they are all in accordance with the idea that PHP 4.x is out-of-date, and that many exploits have been discovered and exploited for that release. Thay also agree that PHP 5.x is an improvement, security-wise.
2)
The common thread in all of the warnings contained in that document is this:
Improperly-written code is a major security risk.
Are you arguing that the PHP developers who may visit this thread should not be aware of these issues? Are you a fan of zombie networks?
3)
SQL injection is one of the oldest attacks against web applications. However, as it is well known, there are many techniques to defend against it:
...
* Using PDO (available via PECL for PHP 5.0, and is included in PHP 5.1 and later)
...
Unfortunately, with PHP 4.x, it is up to the PHP coder to write robust code that is safe against SQL injections. At this time, PHP programs should be migrating to PHP 5.1 and using PDO, which has a safe SQL interface which avoids all of these issues.
So ... if you are a shared hosting provider, you should just tweak the default PHP 4.x settings to protect your server? Well ... you can't. The many SQL injection examples to be found elsewhere invalidate the security of PHP 4.x, and there must be a different security profile applied that encourages the use of the security features found in PHP 5.x in order to keep any server running PHP as secure as possible.
Shall I go on, or are you inspired to investigate the serious security risks inherent in previous versions of PHP and the lack of awareness on the part of scripters and providers regarding it's danger to the infrastructure?
Sure, 5.x isn't completely secure ... but problems have been addressed. And, hopefully, this thread will help with the awareness issues.
In the end, it will be a tighter network, all around.
What other security resources do you use besides SANS and Bugtraq?
If you find them to be more reliable, please include a link, in accordance with the ToS. I use several, myself, and they are all in accordance with the idea that PHP 4.x is out-of-date, and that many exploits have been discovered and exploited for that release.
Thay also agree that PHP 5.x is an improvement, security-wise.
The common thread in all of the warnings contained in that document is this:Improperly-written code is a major security risk.
All the supposedly flawed security features this article deals with come down to the same conclusion: if you don't know what you're doing your programs are at risk.programming in PHP 4.x is perfectly safe, as long as you know what you're doing
Sure, 5.x isn't completely secure
The real problem with this article is it has some very intelligent portions mixed in with a bunch of foolishness.
The latter requires hosters to upgrade their PHP to the latest PHP 5.1. Unfortunately, there has been low take up of the safer versions of PHP due to perceived incompatibilities with much of the PHP software base. Software which is incompatible with PHP 5.x is simply insecure, and should not be run
I agree, absolutely but good luck trying to get hosts to upgrade, it's like pulling teeth and I understand why, too many variables involved and too many different levels of coders and too many different software packages being used.
Poor permissions and planning by many hosters allowing excessive default privileges and wide ranging access to what should be off limits areas.
but this isn't anything to do with PHP itself.
also all of their 'representative samples' of vulnerabilities have nothing to do with PHP itself, they are software packages that use PHP, these are not vulnerabilities in the language itself.
the example used for determining if you are vulnerable for some of these are foolish examples that use methods that should never be used.
the only recommendation they make through the first half of the paper is to switch to PHP 5, which doesn't actually fix any of the problems they demonstrate. They talk about having built in defences against cross site scripting, well, why should it?
The problem, as I see it, is that neither hosts nor coders take enough time learning about security in general not just in regards to PHP. It doesn't matter what language you use, all of these exploits are possible. They are just as possible with PHP 5 as well.
Hosts
none of the above have anything to do with PHP
Coders
I can tell you that if any coder who worked for me did any of the things used as examples in that article I would probably fire them or at least put them on some kind of code review probation and then get them some serious education.
again the things listed above have nothing to do with PHP itself.
PHP is fairly simple to start out with but is a very powerful language and you can do pretty much anything you want. These two things are both bane and boon and make it even more important that people educate themselves about issues such as security.
At this time, PHP programs should be migrating to PHP 5.1 and using PDO, which has a safe SQL interface which avoids all of these issues.
This is distinctly a PHP issue and PHP 5.x provides a real solution that PHP 4.x and below simply do not have. That alone is reason enough to read and understand the article.
Let's not forget that many of the users of these forums are newbies, or people who have been coding by the seat of their pants and may not have realized the security implications of their 'working' but poorly-written code.
I would like to point out, as well, that the advice given in the article applies in no small measure to hosting providers, not just to regular coders. If one is a hosting provider, one should take serious note if one wants to stay in business. Hosting providers are people, too. ;)
And while it may be true that many of the issues do not apply solely to the use of PHP, in the PHP environment they are often more frequently exploited, and so they should be of greater concern to hosting providers and coders than, say, PERL or ASP, which are less-frequently exploited by these same methods.
I must admit that the article is extremely light on specific corrections to make and on the details of the inner workings of PHP, particularly with regard to common PHP functions and ini settings like
safe_modemagic_quotesFrankly, ANY information that could help a coder manage the security of their applications is a good thing. The overly-simple code examples given point to very common errors being made even by experienced professionals (like Yahoo's folks) in many languages. The concepts presented are accurate, and I found them to be refreshing reminders even though I have been coding PHP and many other languages for many years.
It's disturbing when articles such as this are labeled as 'foolish' or 'incredible', when in truth they offer good advice and are fairly easy to understand.
The bottom line, IMHO, is that simply upgrading to PHP 5.x will provide a better security experience regardless of whether the other factors noted are remedied ... which they should be, of course, but regardless of that, just the same. Sure applications will need to be tweaked, but that's the price we pay for writing bad code in the first place. If the code was originally written with security in mind, there would be very little, if any, tweaking to do after an upgrade. At least that has been my experience, managing several production servers as I do. (No public/alien hosting, though ...)
[edited by: StupidScript at 9:41 pm (utc) on July 5, 2006]
I expect more from owasp or any security oriented site/organization
I get very protective of my language of choice and it bothers me when people blame the language for the coder's (or host's) stupidity
You're absolutely right though StupidScript, well posted, I agree with everything you wrote
