PHP web site compromised
php.net users will have their passwords reset. Note that users of PHP are unaffected by this: this is solely for people committing code to projects hosted on svn.php.net or git.php.net."
Posted Oct 26, 2013 11:27 UTC (Sat)
by betanews (guest, #93606)
[Link] (30 responses)
Posted Oct 27, 2013 0:50 UTC (Sun)
by fergal (guest, #602)
[Link] (25 responses)
So the php binary is no more compromised than usual :)
Posted Oct 28, 2013 11:41 UTC (Mon)
by cabrilo (guest, #72372)
[Link] (24 responses)
I developed a number of sites using PHP, and there seem to be great misconceptions about quality of PHP and its security, at least the modern versions (especially 5.2 and up) of it.
When talking about "language design", people talk about problems like badly named functions, e.g. mysql_real_escape_string (which is a wrapper around MySQL C API, see: http://dev.mysql.com/doc/refman/5.0/en/c-api-function-ove...) or the fact that similar functions receive parameters in permuted order.
Some of that criticism is true, but it's also irrelevant. Many languages have confusing API's and irregular naming conventions, but I am yet to get frustrated by it. Most code is abstracted in classes anyway, so if one is using e.g. mysql_real_escape_string on regular basis, as opposed to implementing it once and reusing it in some sort of ORM or such (or better yet, using non-deprecated PDO or mysqli modules), one is doing something wrong.
Other criticism is the fact that you can embed HTML within a PHP script, doing something stupid like:
<li><?php echo $_POST['unescaped_param_from_post']; ?></li>
Most people see that as unsecure by design, but any PHP developer worth their salt knows how unsecure it is to handle $_POST, $_REQUEST, $_SESSION, without proper parsing.
Of course, most PHP coders aren't worth their salt, and out in the wild there is a lot of code where people simply never consider XSS or SQL injections or whatever else can come from the cruel world.
But, how is that a problem of PHP?
I am yet to work on a project in which POST parameters are taken directly from the $_POST array. I always use proper CSRF, XSS, injection etc. protection and that's a part of the framework that I use for any project, so I don't jump through hoops to get it right every time.
There is a plethora of MVC frameworks for PHP out there, and I still didn't use one which doesn't abstract user input in a secure way. Of course, for each sane PHP framework or CMS, there is a dozen of bad ones, but that's what Google and documentation are for.
Don't get me wrong, there are problems with PHP as well. I am sure my code has a number of problems and some security issues. But, none of it is insecure by design, they are just bugs.
E.g. PHP's safe mode was a terrible thing (it was a setting which gave you an illusion of safety), and there are various security issues with the language implementation (but then again, there always are) which get fixed regularly. There are no threads and there are quirks with changing PHP settings runtime.
Also, Apache installations are often badly configured, where admins allow any PHP script in any directory to get executed, which is usually the reason for sites getting "pwned" (script kiddies will try and upload a PHP script instead of an e.g. image and then execute it without problems). But you still would be wrong to blame e.g. Apache (or nginx or whatever) for it. If the admin allows random PHP scripts to get executed, that's their own mistake (and if a bug leads to it, than it's a bug, not necessarily bad design).
PHP also has a lot of things going for it: it's very easy to deploy, the code is very readable (of course, some people hate curly braces, but that's a matter of taste) and it's classes and inheritance system are very clean and easy to follow. It's also widely used, so there are libraries for pretty much anything, which is of course a double edged sword, but again, there are bad libraries for any language...
That's just my 2 cents. I'm not saying PHP is the best choice for everything, but there is a plenty of safe, easily maintainable and powerful sites built in PHP.
Now, let's wait and see what PHP.NET people say about intrusions. Maybe it will be something very embarrassing (at least, more embarrassing than it already is), maybe not, but we definitely shouldn't troll about it.
Posted Oct 28, 2013 12:05 UTC (Mon)
by fergal (guest, #602)
[Link] (2 responses)
Have you read http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad... ? It's quite mind boggling the number of bad ideas involved. Of course it's possible to consciously avoid many in your own code by just not using them (where I work we use a variety of languages and e.g. in C++, a reasonable number of "features" are forbidden). Others though are traps that you always have to be wary of, like ==.
The most horrifying part of that doc to me is
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad...
and the MAX_INT bug in particular. Anyone can have a security hole but not just anyone can have a fix like that.
Posted Oct 28, 2013 13:02 UTC (Mon)
by cabrilo (guest, #72372)
[Link] (1 responses)
Some of the criticism is spot on E.g. bits about spawning new processes, or class attributes and polymorphism.
Other stuff is questionable, like C influence (what's inherently wrong with having wrappers for C libraries?)
Much of his criticism goes to my "so what" category. E.g. sort is a function for sort, rsort is a function for reverse sort, or that procedural part of PHP is C-like while OO part of it is Java-like. So what? Does it make it unreadable?
Also, this whole thing is about security. The article you linked to complains about possibility to make your PHP installation insecure. Yes, it's quite easy to do it, but I know that I, at least, am quite capable of setting up Apache, Postfix, MySQL or anything else and making it as unsecure as I can by simply not being bothered.
And finally, a lot of criticism in that blog is just misplaced: e.g. he complains about the fact that PHP doesn't come in with a built-in XSS or CSRF protection or authentication / authorization system. Why should it? Does any language bundles CSRF protection? That's a framework's job.
Does Python bundle a way to protect yourself against such attacks? No, Django does. And even in Django, you can misuse, if you are so inclined, csrf_exempt() or requires_csrf_token().
If you were to build a site in e.g. Python, or Java, without using a framework, would you have less security considerations than if you were to do the same with PHP?
Posted Oct 28, 2013 13:45 UTC (Mon)
by fergal (guest, #602)
[Link]
Nothing but it probably shouldn't be possible to cause your whole interpreter to segfault due to incorrect use of an API. That's a violation of the layers. If I want segfaults I'll program in C. Otherwise I expect to get errors at the standard level of abstraction of the language, so that e.g. I get a stack trace of _my_ code at the time of the error, not a stack trace of the interpreter.
I think the complaint about XSRF etc is there because PHP was intended to be used to create websites and not much else, so lacking essential tools for creating secure websites seems like a valid criticism. It's incredibly rare to see it used for anything else. If it's not ready for website creation out of the box, what is it ready for?
As for sort vs rsort, there are 12 slightly different sort functions mentioned in that post. Most other languages have 1 (maybe 2: in-place vs copy) and a way to make it behave as needed (PHP's usort, essentially). Yes, some of those 12 only exist to provide "a" and "k" versions but what about natcasesort? What if you want to do an ksort but use the same criteria as natcasesort, in reverse?
This shows a lack of wisdom and good taste (or even just an ability to copy what's done well in other languages).
I've worked with people who will happily just copy that chunk of code from X to Y and modify one line instead of stopping to think how to making a function out of it. These people always have a host of other bad practices and in some cases have written such terrible code that I've actually spent more time dealing with it and fixing it than if I'd just written it from scratch myself.
PHP's API has exactly that feel about it.
Posted Oct 28, 2013 13:41 UTC (Mon)
by sorpigal (guest, #36106)
[Link] (9 responses)
It's a problem with PHP because PHP entices people who are not used to worrying about security and correctness to begin programming. Instead of easing them in to concepts like these most of the PHP world seems dedicated to misinforming them, or ignoring the problem entirely, leading to a situation where more and more bug-riddled code is produced.
The problems with PHP as a language are a few minor things mostly in the implementation, like not being noisy enough when bad things could happen (my favorite example: use of undeclared variables), but the problem with PHP culture is a systemic lack of interest in correctness. Most new PHP programmers will go to php.net and read the documentation, which happily documents use of built-in functions in unsafe ways, and then perhaps will copy/paste some of the snippets from the comments section, which are often naive or buggy. I can't blame the language directly for these things, but the culture surrounding the language is such that no one appears to think it's a problem and more and more new programmers learn the same bad practices every day.
If PHP is where a person learns programming, or learns web development, as appears to often be the case, he will spend months or years unlearning bad habits and learning how to produce good code... if he is dedicated enough to do so and doesn't just stop learning once he knows enough to be dangerous. It's a waste and a shame, and I blame PHP for the fast-and-loose attitude that allows bad practices to continue unchecked. Perhaps it's unfair of me.
Posted Oct 28, 2013 15:55 UTC (Mon)
by cabrilo (guest, #72372)
[Link] (1 responses)
Pure PHP looks like a ready made solution for developing sites. It's not, it needs a MVC framework to make it functional, just like Python needs Django or Web2Py and Ruby needs Rails.
Posted Oct 28, 2013 16:13 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 28, 2013 18:30 UTC (Mon)
by khim (subscriber, #9252)
[Link] (6 responses)
Why not? This is language specifically created to write buggy code. It's the goal of said language, it's raison d’être. It tries to do “the right thing”, but does it extremely sloppily which means that all it's magic quickly explodes in novice's hands and it's really hard to write something robust. My new favorite example is PHP's ++ operator. It's bad enough that it works on strings. But when you'll try to understand just how it works on strings… Perl has smartmatch operator which is so awful that the only thing about it that you actually need to know is “don't use it, period”. Unfortunately most (almost all) language constructs are as magical as perl's smartmatch operator. And you can not avoid them! You only hope is careful control over said magic and this is actually more tedious then in any other language. When you are doing something wrong you are not given errors or even warnings. Heck, most of the time your program actually works! Only when confronted with carefully prepared input it breaks apart. The only two languages with such a property which I know are PHP and JavaScript. And I'm not even sure which one is worse: PHP is awful, sure, purely from linguistic standpoint it's not a even a contest, but… there are very simple solution—just don't use it and you are golden. JavaScript is distant second in this contest, but there are problem: PHP's solution just does not work! Quite often you must deal with it and substitute is not an option!
Posted Oct 28, 2013 20:20 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Oct 29, 2013 23:51 UTC (Tue)
by nix (subscriber, #2304)
[Link] (3 responses)
;P
Posted Oct 30, 2013 7:47 UTC (Wed)
by micka (subscriber, #38720)
[Link] (2 responses)
Posted Oct 30, 2013 15:17 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
[1]Now that I think about it, would one author would have to defer to another even if the savior isn't bound by license to the other? Would that count as criteria for "must save"?
Posted Oct 30, 2013 19:18 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Oct 28, 2013 15:03 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
The problem is usually that argument order is flipped coupled with PHP's willy-nilly implicit casts. It makes *finding* flipped arguments harder than it should be.
> of course, some people hate curly braces, but that's a matter of taste
IME, it's not the curly braces, but the forced sigil ($) and the stupid choice of namespace token (really, '\'?).
Posted Oct 28, 2013 17:22 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (8 responses)
The problem is that any language which has both of these characteristics and does little to stop you from shooting yourself in the foot is inevitably going to lead to inexperienced developers doing dangerous things, and since PHP tends to end up facing the Internet that results in badness. Ideally there'd be a language with the gentle difficulty curve of PHP which let you do useful things without making it quite so easy to screw everything up.
Posted Oct 28, 2013 17:44 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
I think your assessment is spot-on. The biggest liability of PHP at the moment is IMHO reams of bad example code lying around on the 'net. Since it's perhaps (for better or worse) *the* language for beginners, there will be lots of cargo-cult programming.
I think the best service PHP fans could do to their language is to hunt down anti-patterns (sprintf SQL query generation, regexp XML parsing, etc. etc.) and counter them with current good practices.
Posted Oct 28, 2013 18:51 UTC (Mon)
by khim (subscriber, #9252)
[Link] (6 responses)
There are few pieces where C i magical and even that often is too much (the fact that it can implicitly convert float to int rarely helps and often hurts), but PHP is magical from the bottom to the top. You can not actually fix that, the only way is to pick some other language. Unfortunately that's impossible. The camel has two humps and the only way to make language suitable for the Joe Average is addition of some kind of “common sense” to it. Then one can “talk with computer” and “look, ma it can guess what I'm trying to do!”. Of course the flip side of this very same property is inherent insecurity: since your language (Ok, interpreter of your language) is trying to second-guess you intentions with the help of bazillion of complex rules it sometimes does mistakes. Which can then be exploited by adversary.
Posted Oct 29, 2013 17:31 UTC (Tue)
by oldtomas (guest, #72579)
[Link] (4 responses)
Yes. To be fair, C's magic is more than one would expect. See for example <http://blog.regehr.org/archives/213> and following. With aggresively optimizing compilers and reordering processor architectures, the amount of magic beneath C is downright scary.
(I'm a big fan of C, nevertheless, but fair is fair ;-)
Posted Oct 29, 2013 17:48 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (3 responses)
Posted Oct 29, 2013 17:56 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Oct 30, 2013 1:21 UTC (Wed)
by hummassa (subscriber, #307)
[Link]
Simple: C (and the C subset of C++ also) is still a glorified semi-portable assembly language. if you overdefine the language, you harden some behaviours that will be inefficient when you port to other architecture.
Good? Not really.
But workable. And that's why none of the "C successors" ever really caught on as kernel implementation languages, for instance. Once you need to write something in "readable assembly", C is the answer...
Posted Oct 29, 2013 21:28 UTC (Tue)
by oldtomas (guest, #72579)
[Link]
Right you are :-)
Magic enters when it becomes difficult to build up a mental model of the border to the undefined. Or, as khim puts it "...hundreds of them".
Not criticizing compiler writers. We users stake our expectations on the optimizer quite high. We get the magic we pay for ;-)
Posted Oct 29, 2013 23:55 UTC (Tue)
by nix (subscriber, #2304)
[Link]
(<old-fart>grumble grumble can nobody read any more</old-fart>)
Posted Oct 29, 2013 9:12 UTC (Tue)
by Tobu (subscriber, #24111)
[Link]
You seem to be saying that because you, and programmers worth their salt, can write reasonably good code the language isn't at fault. Languages with a good design philosophy just don't make their standard libraries that bug prone; good API design focuses on usability, which means making things both easy to use and hard to misuse (ease of use alone leads to DWIM which leads to subtle bugs).
For the sake of comparison, in Python you can almost always name the arguments you pass to a function; Python 3 takes this further by supporting keyword-only arguments that can't be used without naming them. The subprocess module takes commands as lists; it's impossible to have shell injection unless you go out of your way to invoke a shell or introduce your own parsing. The same module's documentation opens with convenience functions like subprocess.check_call and subprocess.check_output, which fail on non-zero exits, and proc.communicate(), which is simpler than implementing your own io loop and not prone to deadlocks. Functions wrapped from libc throw exceptions instead of returning a code that can be silently ignored; 3.3 has a reworked exception hierarchy that makes it easy to catch only expected failure modes. All objects than need resource cleanup (files, temporary files, processes) support it in a uniform way (a with statement) which doesn't require remembering the specific implementation (flushing, deleting, waiting or killing).
Posted Oct 28, 2013 8:16 UTC (Mon)
by oldtomas (guest, #72579)
[Link] (3 responses)
OK, I'll bite:
No, this time it does have to do with browser security. Whoever thought it'd be a good idea to teach the browsers to download random code off the 'net and *execute* it... I'll better censor my words.
Oh, yes. There's sandboxing and that. This is the weak "we'll fix the issues one by one as they come up", glossing over the fact that the very idea is broken. Javascript (or whatever the executable content du jour in the user agent is called) should be off by default.
Posted Oct 28, 2013 21:28 UTC (Mon)
by pboddie (guest, #50784)
[Link] (2 responses)
I'm serious: when a site uses 99% of the CPU to scroll adverts, who benefits apart from the power company?
Posted Oct 29, 2013 1:43 UTC (Tue)
by pr1268 (guest, #24648)
[Link]
I'm sure the computer/device vendors (including CPU manufacturers) reap some rewards. "...Honey, this Web page is too slow... Let's go to $RETAILER and buy a faster PC!! Oh, and how about calling up $INTERNET_PROVIDER and getting a faster connection?" I'm only being half-facetious here; I've actually witnessed these reactions from naïve people I know after they became addicted to various Web sites. But, I LOVE your line. QOTW-worthy! And to think all these script-heavy Web pages were a big power utility conspiracy. Amazing!
Posted Oct 29, 2013 14:12 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
I would argue it pushes the update train harder and so helps hardware companies (and the carriers with the new contracts) more.
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
Of course, most PHP coders aren't worth their salt, and out in the wild there is a lot of code where people simply never consider XSS or SQL injections or whatever else can come from the cruel world.
But, how is that a problem of PHP?
PHP web site compromised
PHP web site compromised
PHP web site compromised
I can't blame the language directly for these things.
$a = '2d9';
$a++;
$a++;
echo $a;
Can you even guess what will be the result? And it'll be the result?PHP web site compromised
It also has an awesome license. Seriously, why didn't I think of including
PHP web site compromised
If you are caught in a dire situation wherein you only have enough time to save one person out of a group, and the Author is a member of that group, you must save the Author.
in my software before? I mean, yeah, GPL-incompatible, but, hey, it could at some point in the future save my life, as long as not too many other people use the same license! How many copyright licenses can you say that about?
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP has features that allow you to shoot yourself in the foot. That's fine - so does C, and I'm a big fan of C.
Ideally there'd be a language with the gentle difficulty curve of PHP which let you do useful things without making it quite so easy to screw everything up.
PHP web site compromised
PHP web site compromised
Of course, but who do we have hundreds of them? This makes life easier for compiler writers but miserable for users. Most of them should have been unspecified or implementation-defined instead.
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
Unfortunately that's impossible. The camel has two humps and the only way to make language suitable for the Joe Average is addition of some kind of “common sense” to it.
You appear to be taking a paper that says 'nobody has ever looked at this before, but in our one test with this small sample we found something that might be interesting' and generalized it into a universal law. This is not so much bad science as outright scientific mythology.
PHP web site compromised
PHP web site compromised
PHP web site compromised
PHP web site compromised
I'm serious: when a site uses 99% of the CPU to scroll adverts, who benefits apart from the power company?
PHP web site compromised