PHP is as secure as any other major language

https://www.acquia.com/resources/podcasts/acquia-podcast-119-greatest-hits-2013-69-php-security-anthony-ferrara

by ayi • 13 years ago

39 75 13 years ago

thirdsight3• 13 years ago

Probably contrary to common belief here but the headline is correct IMHO.

However this is because web programming as a whole is a crock from top to bottom. PHP doesn't really add or subtract from that other than lowering the barrier to entry with respect to compromising your server through stupid architectural or coding decisions.

If we wrote our web pages in C, it's be just as bad. Rails has a terrible history of vulnerabilities. Many times I've seen injection attacks in audited Java and C# applications.

Everything can be a turd in the wrong hands.

mschuster91• 13 years ago

In contrast, I'd say a pure-C web page would be way easier to open to attacks than a PHP one.

String copy issues (termination), buffer/array overflows, machine-code (R)CE vulnerabilities,... an endless list of stuff which the PHP runtime actually protects a novice of.

cleverjake2• 13 years ago

and a webpage written in assembly would be even more likely to be able to be attacked. Its a silly argument. No one is saying consider C for you next website.

thirdsight3• 13 years ago

Yes but it only takes one eval or config flag set wrongly for that to be moot.

It's perfectly possible to write a pure C web page that is 100% secure. It just requires experience.

The same with all other languages. PHP doesn't protect the novice, neither does C. Experience does.

cleverjake2• 13 years ago

Probably contrary to common belief here

I don't think that is true. PHP just makes it easy to write anything - including insecure code. And the bigger issue is that the community around PHP often shares code that is insecure without knowing that it is, or why that would be important.

The C argument is a red herring - its not meant for web pages. (web servers, though...)

Rails is not a language. It is a framework. Wordpress has tons of vulns as well.

I agree that "Everything can be a turd in the wrong hands", however, one of the biggest parts of, er, "turd prevention" is the culture and tribal knowledge around a language and best practices. PHP struggles with that because it is so easy to learn and so easy to do something bad.

einhverfr4• 13 years ago

I think one issue is that there are a number of somewhat dangerous foot-guns security-wise in extension-land. For example, last I checked the pgsql extension had implicit, global, anonymous database connections.

Culture is part of it, but part of the culture is figuring out how to ensure that programmers can verify security. Yes, anyone can write insecure code in any language, but can anyone write provably reasonably secure code in a given language? That's a far harder question. I don't see PHP scoring very well in that regard.

draginator3• 13 years ago

PHP makes it easy to do easy things terribly, but makes it extremely difficult to do normal things well.

SilkRoadie• 13 years ago

I would be suprised if this is a revalation to many people. PHP itself has been pretty solid for a while.

PHP had a bad wrap for a good reason. It deserves it. Looking past the various naming inconsistencies etc, `register_globals` was a terrible idea. Then `magic_quotes` was hardly much better. Not to mention the numerous "tutorial websites" who ignore security altogether with their advice..

In recent years PHP has improved drastically. Unfortunately the stigma around previous version has persisted with many people ill informed about what modern PHP looks like.

einhverfr4• 13 years ago

I think the fundamental question is how easy it is to shoot yourself in the foot without having any clue as to what you are doing wrong.. Comparing PHP to C is somewhat of a bad comparison since C is famous for security gotchas. If you are comparing PHP to C security-wise.... What's the comparison? All the security of C with all the performance of a scripting language?

Now, the core language in PHP is a lot better than it used to be but in the extensions you still see all kinds of braindead behavior like implicit (yet both global and anonymous) database connections and the like. Since so much of PHP is in extension-land this is somewhat troubling.

chrisrhoden• 13 years ago

I would be genuinely shocked to hear anyone had made the point this article is arguing against since register globals was disabled by default. PHP is awful for all sorts of reasons, but the security angle here feels like a straw man.

orf3• 13 years ago

I work with a group of penetration testers (who audit the security of websites, ranging from top 100 sites to smallish ones), we find a lot more issues with PHP sites than any other. .NET sites are often the most secure.

That being said, I once tested a ancient Java web app that recommended you use IE 5.5 (for the latest features). The people who made it decided it would be a good idea for the site to send the database credentials to the browser, which would then send them when requesting data. I face palmed pretty hard.

gabordemooij5• 13 years ago

That still does not mean the language itself is insecure. In my opinion this rather indicates the developers responsible for building those vulnerable sites lack some knowledge about proper web security.

abjorn2• 13 years ago

I believe that was more or less the point he was making - regardless of the language or platform developers without proper understand can and will make security mistakes.

rbsn2• 13 years ago

Exactly! Just because you choose to drive your car into a brick wall at 100mph, it doesn't mean your car is unsafe.

einhverfr4• 13 years ago

Sending database credentials to the browser btw may or may not make sense. It really depends on context. If the db is enforcing users' security (which would be the case if you want to share security logic across apps possibly written in different languages) and it is an internal app with limited numbers of users, this makes a lot of sense. For a public internet site, however, it makes very little sense (since you likely have lots of users with essentially the same permissions).

In LedgerSMB, for example, we use app login credentials as db credentials for internal users, but for customer/vendor portals, we use a single user account for the portal. There are a lot of reasons for this but PostgreSQL is flexible enough one can (relatively easily) limit most users to the LedgerSMB app if one wants (via pg_hba.conf). The goal however is to allow non-web apps with the same credentials and security enforcement and we already have some of those.

So it isn't necessarily a facepalm. It really depends on context. There can be valid reasons for it but those are not in the context of a public-facing web site. I.e. if you expect users only to access the db through a single app then you don't want to use it but if you want the db to be accessed through a group of apps then using the db as a SSO technology is actually pretty smart.

orf3• 13 years ago

It was only a single app, and the database server was pretty much unprotected. As far as I can remember it did most/all of its access controls via JavaScript - it was truly terrible.

Sure there are situations where it is OK, but as a rule of thumb it's not a terribly good idea.

mephi5t0• 13 years ago

Just because you tested more secure .NET site than less secure PHP sites doesn't mean that PHP is less secure. It means you tested more secure .NET sites compared to number of less secure PHP sites. If you flip a coin 10 times and you will get 10 tails it doesn't mean that the coin is broken or faulty. Random numbers are random.

morganherlocker3• 13 years ago

If you flip a coin 10 times and you will get 10 tails it doesn't mean that the coin is broken or faulty.

It might be. At a certain point, the coin is more likely "broken" (or rigged somehow) than actually flipping tails every time. The chances of flipping a coin 10 times in a row tails are ~1/1000, so I do not think this is in the range, but at 100 flips, I would say that it is much more likely that the coin has been tampered with.

orf3• 13 years ago

With a sample of 10 that makes sense. We have done over 150 PHP tests over the last couple of years and the average number of issues is higher than other technologies. What would account for that bias?

programminggeek• 13 years ago

I think there is a subtle, but important thing that the author is missing because, while objectively, PHP as a turing complete language(I believe) you can write basically anything in PHP both good or bad, there is the question of what the language/framework/tools/community allows for or encourages.

In the earlier days of PHP, it was incredibly common to build SQL via strings and nobody thought too much about it. Over time things have evolved and a million little frameworks have sprouted up and it's less of a problem, but that doesn't mean that PHP doesn't have a terrible history behind it of a community not knowing or caring as much about security as they should.

Then, there is the fact that php files just sit on the server and can be executed arbitrarily by just navigating to that file. That is a real security problem in the case that someone is able to upload a php file to a machine. Yes, I know a lot of frameworks make this harder to do now, but by default apache/php lets you do this and you could argue it's one of the real strengths of PHP(ease of deployment).

Last, because PHP is the biggest language it is the biggest target, which means that writing secure code is that much more important. So many PHP projects are open source, so if a vulnerability is found and you don't upgrade your Wordpress or Drupal or Joomla or Magento or phpBB or whatever else app you are running, your site is very likely to be compromised just because you aren't staying up to date with updates, and A LOT of people don't update their software, systems, or packages like they should.

So, PHP from a purely objective standpoint might be as secure as anything else, but the human factors surrounding PHP make it a lot worse in my opinion than other languages/platforms/frameworks from a security standpoint.

ceejayoz2• 13 years ago

I frankly wonder how much of PHP's poor reputation is directly related to the high Google PageRank of W3Schools and their awful PHP/MySQL tutorials.

wil421• 13 years ago

I had a teacher who recommended W3Schools to her students, she thought they were related to W3C and she was shocked to learn they weren't.

wereHamster• 13 years ago

    "... you can write insecure code in it," he underscores his point,
    "but that's a fundamental problem in every single programming language"

No, there are languages where you can't write insecure code, where the compiler doesn't allow it and will warn you when you do.

gabordemooij5• 13 years ago

Can you give an example? In the context of web development of course...

adamnemecek4• 13 years ago

http://www.impredicative.com/ur/

http://plv.csail.mit.edu/ur/

gabordemooij5• 13 years ago

Probably answering my own question here but now I think of it, there is no language I can think of that catches SQL injection etc, but there seems to be server that does!

http://www.hiawatha-webserver.org/

I have no experience whatsoever with this beast but it says it kills SQL injection, XSS etc. Curious whether this would be effective.

morganherlocker3• 13 years ago

Its been a while since I did any ASP.Net, but I remember some sort of error that would be thrown by default for common sql injection or script injection patterns on user inputs. There were still many many ways to screw things up, but this probably prevented quite a few attacks for extra lazy/ignorant coders (we have all been there at one point or another).

dbpatterson• 13 years ago

Not sure if I agree with OP, but this language/framework makes most common web vulnerabilities impossible: http://impredicative.com/ur/

kijin• 13 years ago

there are languages where you can't write insecure code, where the compiler doesn't allow it and will warn you when you do.

Where is this wonderful language that throws compiler warnings when the code contains an SQL injection, XSS, or CSRF vulnerability?

adamnemecek4• 13 years ago

http://www.impredicative.com/ur/

Shish2k• 13 years ago

Not a complete solution, but I thought perl's "taint" feature was a brilliant idea, and I wish more languages did similar. In short, data provided by the user is automatically marked as "tainted", and cannot be passed into a shell command, an SQL string, printed into the HTML, etc, without being explicitly converted into a safe form.

(I'd particularly like it if it were possible for the user to define their own types, so we could have "raw string", "validated HTML string", "validated SQL string", etc - and also "distance in meters", "distance in feet", etc -- and it wouldn't be possible to operate on different types without explicitly converting them into compatible forms)

plorkyeran• 13 years ago

Haskell with Yesod comes as close as is practical (if you explicitly tell it a string is safe to use in a certain context, it will not magically figure out that you're wrong). If you loosen the requirement to just "secure by default" rather than "insecure code fails to compile", most modern web frameworks have built-in automatic CSRF protection and default to escaping all strings when inserting them into HTML.

splawn• 13 years ago

any language could print out a hardcoded string of your root password

abjorn2• 13 years ago

That's a bit of a broad statement, maybe - I'd be interested to see a general purpose language that will not allow you to write insecure software, I have a hard time believing that exists.

But you're coming from the right place - it's absolutely the job of the programming language to at least make it more difficult to do so and encouraging good security practices, and PHP does not do a very good job of that. Then again, I write JavaScript for a living so I suppose I don't have much room to criticize on that front.

romanovcode• 13 years ago

Nobody said it wasn't secure.

IMO it's just a bit easier to write buggy/vulnerable code in PHP than other languages. Or maybe I'm just a hater, don't know.

draginator3• 13 years ago

No. There are plenty of people that say PHP itself is insecure.

They are right.

Sure anybody can write insecure code in any language, but PHP makes writing secure code much more difficult then other languages and even if you do write secure code the interpreter itself has a pretty terrible track record.

nikic• 13 years ago

Some languages make writing secure code easier than others. When it comes to web-related code of semi-good programmers, I'd conjecture that the amount of vulnerabilities is directly proportional to the amount of magic involved. Early PHP had lots of magic - things like register globals or magic quotes. By now no sane developer uses those things anymore (well, and they were removed). The plethora of recent Rails vulnerabilities was also caused by various magical behavior, especially in parameter parsing. (Actually, I'd expect modern Rails code to have more vulnerabilities than modern PHP code, because they still have a lot more magic involved.)

philjackson• 13 years ago

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

morganherlocker3• 13 years ago

The most common vulnerabilities are in the frameworks and libraries surrounding a language, not the actual language (there are exceptions). On top of that, user/developer sloppiness is even more common than security bugs in common frameworks. I would bet most servers that get compromised do so through having things like root/password1 credentials or extremely obvious sql injectable code.

pessimizer2• 13 years ago

Backed up by:

1) You can write insecure code in any language, and

2) Platforms written in other languages have security vulnerabilities.

When your argument in defense of a computer language can be applied to every single computer language ever invented without any changes, it's a sign that it's not really an argument.

Here's my argument about how I'm as good at ping-pong as everyone else:

1) Other people can play ping-pong badly.

2) Other people have lost ping-pong matches.

j452• 13 years ago

The people who the software is for, end users, rarely care which language/framework things are written in.

We as developers can get too focussed on optimizing and making our own lives easier and the net output to the end-user is relatively the same.

This does not mean to ignore what's out there that's new, but if you see a platform re-inventing features and libraries that have existed already for years in other platforms, you might be in for a few years of patching together things.

pessimizer2• 13 years ago

Is this in reply to my comment, or just a a series of random assertions?

meandthebean• 13 years ago

I think the point of the article is that most of the arguments made against PHP can be made toward any other language as well (i.e. you can write insecure code with it), so the defences can be made for any language as well.

It's unfair to say that a vague defense to a vague accusation is invalid. If I said you were the worst ping-pong player in the world because you lose some games I think the arguments you listed would be a valid defense.

rbsn2• 13 years ago

I am confused as to whether this article is trying to compare the security of the language implementations (PHP Interpreter, JVM, Ruby Interpreter, V8) or what vulnerabilities can be exposed in programs written in the language (SQL injection, non thread safe, stack overflows) etc.

kubabrecka• 13 years ago

What the article completely ignores is the fact that there are plenty of security issues in the implementation of the PHP interpreter. Just compare the number of security advisories for bugs in PHP itself to bugs in Python/Perl/Ruby/etc. There is a difference.

btilly7• 13 years ago

The headline is false. As repeated problems like https://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable... demonstrate, PHP is routinely vulnerable to security problems that other languages are not.

The reasons are a combination of things. The language tries to volunteer to do too much for you by default. The environment it is run in tries to do too much for you by default. The past defaults were even worse. A lot of available software in PHP was written with no attention to security, and it still shows. And it has attracted a community that fails to recognize these things as problems.

Yes, in theory you can write PHP and make it as secure as anything else. In practice it doesn't happen that way. And until PHP developers stop patting themselves on the back and assuring themselves that they are really OK, they will continue to have big problems.

ayi6• 13 years ago

If you blindly trust user-generated data and use it as database connection credential or in a SQL string, i do not think this is a problem of PHP.

If you don't use prepared statements with PDO, i still don't see this as PHP's problem. This is a unqualified programmer problem.

refer to: http://www.phptherightway.com/#databases

btilly7• 13 years ago

You don't get it.

In the case of MongoDB, a system that was designed to make SQL injection attacks a non-issue, in which they were a non-issue in other languages, were noticed several years later to suffer from SQL injection attacks in PHP and PHP only.

The cause is that the language, behind programmers backs, could let users supply a data structure where it looked like you'd only get a string. And would only have had a string in other languages.

PHP is not the only language with problems like this. For example Ruby on Rails about a year ago had a series of bugs that were due to a similar design flaw. But this type of mistake has, for years, been more common in PHP than in any other programming environment. And PHP programmers like you who think that they can just follow a couple of well-known guidelines for databases and be safe, who fail to understand when you are told directly that the problems are bigger, are a big part of why PHP continues to have these problems.

draginator3• 13 years ago

PHP is as secure as any other major language

Well this is patently false. You can find a significant difference in the vulnerabilities found with PHP interpreter and core libraries then you find with other languages.

It's not just that people program badly with it, it's a badly programmed language that sets users up to fail and even when they do program securely PHP itself is insecure.

Lets see how PHP compares....

PHP (348): http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id...

Python (17): http://www.cvedetails.com/product/18230/Python-Python.html?v... and also (20): http://www.cvedetails.com/product/2147/Python-Software-Found...

Perl (20): http://www.cvedetails.com/vendor/1885/Perl.html

Ruby (42): http://www.cvedetails.com/product/12215/Ruby-lang-Ruby.html?...

And so on and so forth. The only thing that rivals it is Java.

semerda• 13 years ago

The big problem here is too many "overnight learn to code in 24 hours" developers choose PHP to develop by "cut & shut approach" using code they acquired online from a dingy website. This yields insecure implementations. And the cycle begins over and over.

Better languages have a far superior way to implement code following standard industry practices & conventions. For example, how many ways are there to get the length of a string in PHP vs say Python?

When there are too many ways to do some basic manipulations you start getting many different code implementations doing the same thing. Also how many Built-in Functions are included in PHP vs other languages? Too many is the answer.

Shall we even touch up on Unicode support? lol..

PHP is as secure as any other major language

Related Stories