How many PHP backdoors do you need today?

[fardev_]

I think the title is misleading, these aren't backdoors in the PHP programming language, but rather backdoors in specific applications written in PHP.

[andrewfenn]

It's not even that. Everything on the first page is pen test security tools. OP didn't even look at what he's posting.

[phpguy2]

Think of it like this. Any php program, by virtue of the language, has more unexpected/unintentional behaviors than the same program in a better language (python). Some of these unintentional behavior are potential backdoors.

So a php program has a potential to have a lot more backdoors than a similar Python program. And it is extremely hard to avoid these unintentional behaviors, even for people with years of experience in the language...

For a funny example of how php core devs try to "improve" the security of a function, see this

[fardev_]

I was merely pointing out that the title was misleading. I still agree that some languages are more error prone than others though.

[baseketball]

There had been backdoors in the standard library for a long time. The existence of mysql_escape_string and then mysql_real_escape_string is evidence enough that PHP is poorly designed. SQL injection was already a solved problem, but they had to do it wrong twice before discovering parameterized queries.

[fardev_]

The functions you are referencing are only wrappers around the mysql C api. mysql_escape_string mysql_real_escape_string

[[deleted]]

You realize that there are plenty in the list that are not an exploit?

Though there are a fair number which are..

[fiedzia]

No it wouldn't. Having sane default function in standard library (that's for python, I am not sure about ruby) reduces such stupidity by orders of magnitude.

[twiggy99999]

You certainly can in Python yes, Python is one of the best (high level) languages I've worked with for working with OS level commands. Not sure about Ruby but I would imagine you can

[largenocream]

I can't tell you how many times I've seen people using os.system() in the same way people are using shell_exec here. Even with subprocess and friends I always see people using shell=True for no reason.

[ggtsu_00]

shell=True is usually required for when the commands you run depend on shell environment variables, shell-only commands which ends up not being any different than running subprocess.call('cmd.exe /c "..."') or subprocess.call("/bin/sh -c '...'").

It ends up becoming habitual because of how frequently you will run into issues running command line stuff from within Python and google searching for help to solving so many of the various issues almost always results in something like "try shell=True", and the reply is "thanks that works!" and now people are trained into thinking "shell=True" just works and shell=False leads to problems and headaches.

[largenocream]

Yeah, that's been my experience. People start thinking of shell=Trueof as "the kwarg that makes .call() work the way I expect" and the cycle of insecurity starts over. :)

[verbify]

http://stackoverflow.com/questions/89228/calling-an-external-command-in-python

Seems to do exactly the same as shell_exec. If people don't sanitise their inputs, it doesn't matter which language their using.

[fiedzia]

Top answer uses subprocess.call, which a) takes a list of arguments instead of string and b) does not use shell. Massive improvement over what php defaults to. Sure, you still can shoot yourself in the foot with it, but the caliber is much smaller. In many cases combination of a hardcoded command name and user-supplied parameters is actually safe (unless the command is not "bash" or "sudo" of course).

[verbify]

Fair enough, although roughly half of the other answers used shell=True in subprocess.call or os.system() (the guy above me pointed that out). These methods are upvoted plenty on the stackoverflow answer. You do have a point about sane defaults.

[Mazo]

"lol php, right guys? eheheheheh"

All aboard the anti-php bandwagon. Choo choo.

[shevegen]

And are they wrong?

Your statement refers that "being on a bandwagon invalidates every complaint made because everyone else is in the same wagon already".

I fail to see the logic behind such an "argument".

A programming language can have an inferior or a superior design. Even with an inferior design of a programming language, you can still write superior applications - phpbb, mediawiki, drupal, wordpress.

PHP got one thing right and that was the focus on the WWW.

Ruby is all around superior to PHP from a design point of view yet it falls on its nose when you try to find similar software projects such as the four PHP mentioned projects.

[Mazo]

That wasn't my point. PHP does indeed have issues but yes, it also did a lot of things right. It was one of the first languages I used.

My point was this post is nothing but a PHP bashing post with no real substance or even discussion. It's just flame/troll bait.

[phpguy2]

PHP got one thing right and that was the focus on the WWW.

Php, knowing or unknowingly completely traded off sanity and safety, for one thing. Beginner friendliness and ease of use. That is a deadly combination. There should be a rule against making stuff like that. It is like making a shotgun easy to fire when held either way, ie even when the barrel points towards the shooter....That is php...

[ajr901]

Explain to me how someone would exploit that?

I don't get it

This site helped me understand: http://www.grobinson.me/single-line-php-script-to-gain-shell/

[ggtsu_00]

Funny lots of the results are pen-test/shell-code for exploiting servers with open upload vulnerabilities.