Hacker News Reader

Comment by btilly | Hacker News Reader

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.

View on HN

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

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.

If you use square brackets in query string (passwd[$ne]=1) PHP converts them to arrays. I use them daily like (first=value&arr[]=foo+bar&arr[]=baz). I still can't see the problem with that. You should not trust any user-generated data. This is not a PHP problem.

You don't see the problem because you don't understand the wisdom of rule 5 in http://cr.yp.to/qmail/guarantee.html.

When programs volunteer to parse things in possibly unexpected ways, you tend to open up security holes where most people wouldn't expect to find them. In that situation, no matter how much you jump up and down and point the finger, the convenience of parsing is itself a real problem.

You've been pointed to a case where real programmers had real security problems stemming from PHP's willingness to parse when programmers using PHP did not expect PHP to do that because other environments don't. You fail to see that this is a problem with PHP, and only think of it as a problem with programmers.

Your willingness to accept that programmers should need to know more than they should, combined with an unwillingness to rethink your beliefs when presented with evidence that this has lead to real problems, is a perfect example of my point that PHP, "has attracted a community that fails to recognize these things as problems."

I'm at least trying to understand you.

But i still say, if you expect a string from a query (address bar) but you don't type-check it before using it somewhere, it's your problem not php's. (by the way i'm a ruby programmer in my 9-5 work)

What you are saying is that it is your problem if you do not know PHP well enough to know everything that it is going to possibly do behind your back. And you say that in full knowledge of the fact that PHP is widely used by the exact kind of novice programmer who are least likely to be able to competently do that. And you fail to notice that those two facts combine for a recipe for a constant stream of security holes.

Figure those things out, and then you will understand why I think that PHP is worse for security than other languages.

"RTFM" is the correct response in this situation. PHP converts []s in url to arrays. You should know that, because you are the programmer. You should know your language. What if i send "anything' OR 'x'='x" as parameter? Does SQL injection also PHP's fault or does it programmer's?

When you compare with other languages, PHP does a lot more behind the programmer's back, has a far larger set of built-in functions (many of which have bad interactions) and has a user base with on average less experienced programmers. And yet you think that RTFM is the answer.

Yes, programmers need to RTFM. Security isn't free. But PHP makes it much, much harder than it should be. And does so with a base of users who are not prepared to do it well.

If you want to get real security, you don't get it by simply saying, "Bad developer!" You do it with layering defenses. Developers who know what they are doing, using APIs that are clearly defined, with languages that do not introduce unnecessary potential security issues, with development practices that catch issues, with monitoring that notices stuff, and so on and so forth.

Yes, developers should RTFM. But if RTFM is the beginning and end of your thinking, you've got disasters waiting to happen. And the results are abundantly clear with PHP.

Now I'm done with this conversation. You are missing what should be a pretty basic and obvious point. PHP makes security harder than it should be. Not impossible. But harder than it should be.

No I think YOU don't get it.

Anything sent to a web app via HTTP is user generated content. You can't assume it is ANYTHING.

That's what i'm saying. You shouldn't trust any data from sources like cookies, query strings and even http headers. If you blindly trust them, this is not a problem of programming language. You should sanitize data before using it.

The point is that if you build a data structure for MongoDB in any language other than PHP, and just include the user parameter where it belongs, the only thing that the user can supply there is a string and it is easy to verify that there is no possible security problem. MongoDB's APIs were designed around this fact as an easy way to avoid the possibility of SQL injection type attacks.

In PHP the exact same approach turned out to be a security hole because if the user supplies the right input you get a data structure that is meaningful to MongoDB.

As you say, you shouldn't assume anything about user generated content. But PHP's willingness to parse that input and turn it into something the programmer didn't expect to see often means that user generated content is harder to deal with in that language than you should reasonably expect it to be.

Seriously how hard is it to call filter_var() or even is_string() to ensure its a string?

It is impossible if you don't know you have to.

For several years if you followed the examples in the MongoDB docs, you wouldn't have known you had to, because the people who wrote those docs didn't know you did either.

So not understanding the language you are writing an extension for is more acceptable to you than allowing a basic but useful way to accept semi structured data in http requests?

Reply on news.ycombinator.com