The state of PHP security

December 20, 2006

This article was contributed by Jake Edge.

PHP security has been much in the news lately, mostly centered around the resignation of Stefan Esser from the PHP Security Response Team. His stated reasons for leaving are rather alarming, and he indicates a pattern of slow responses to security holes within the language itself. Others, including Zend co-CTO Zeev Suraski, disagree and chalk it up to a personality conflict between Esser and the rest of the team. A recent look at the National Vulnerability Database (NVD) specifically for PHP related security issues also highlights some of the problems with PHP. It is time, it seems, to take a look at the state of PHP security.

PHP is touted as an easy language to use to write web applications, particularly those that use a database for storage. There are no end of PHP tutorials available on the web that will help readers to get a web application up and running in short order. Unfortunately, many of these tutorials completely ignore security and invite their readers to create applications that suffer from SQL injection and other security flaws. This example (from the top ten results of a Google search for 'php tutorial') explains how to update a record in a MySQL database using single quotes around the values that come in from a web form. It also describes how to display data in ways that allow for cross-site scripting.

As described in another security page article, the proper way to handle database queries with user supplied data is by using placeholders. PHP does provide ways to do that, using the PEAR database API, but finding information about it is non-trivial. It certainly is not promoted by the PHP homepage, which tends to push the included, easily abused, MySQL interface.

Because PHP strives to be easy to use, its developers have added features that have caused all manner of security problems. The worst offender is the register_globals 'feature' which automatically instantiates PHP variables from the CGI variables that are passed in a GET or POST. While it does make it easier for programmers to access these values, it also allows attackers to set the value for any uninitialized variable in the PHP program. Because PHP is a dynamic language, variables do not necessarily need to be initialized before they are used and many programs relied on that feature. When combined with register_globals, this practice leads to easy exploits.

register_globals has long been turned off by default in PHP, but there are a huge number of applications that still rely on it. Many PHP web hosting companies have it turned on because their customers demand it, but it is very difficult to use the feature correctly. There are PHP modes that warn of using uninitialized variables, but those warnings typically end up in a log file somewhere which may not be examined frequently. It is an extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems to think should have been left on by default.

Other poor design choices include the 'magic quotes' feature that gives the illusion of removing SQL injection issues without actually providing that protection. Another is the ability of the PHP include directive to take URL arguments; this has been abused by attackers to pick up their scripts and have them run on the victim's server. Unfortunately, these features get into the language and are used making it difficult to remove them later.

There are various projects to improve upon PHP security, including Esser's Hardened-PHP, as well as efforts, such as the PHP Security Consortium, that seek to educate people about writing secure PHP code. Unfortunately, many of the open source PHP projects do not provide good examples for budding PHP programmers to emulate; they either rely upon various PHP misfeatures and/or they were written by programmers without the requisite secure coding skills.

The existence of these projects (and other similar ones) certainly provides an indication that the security problem with PHP is acknowledged by some. PHP proponents tend to take a 'blame the user' approach that is reasonable in some ways, but fails to recognize some of the inherent issues with PHP itself. If you target inexperienced web application programmers, you can hardly be surprised that they do not have fundamental security skills.

Security seems to fall somewhere below simplicity in the minds of the PHP language developers; that makes it more difficult to have secure PHP applications. Security is a hard problem and any attempt to 'dumb down' a language is likely to run into security issues. Encouraging amateur programmers to write web applications is unlikely to produce secure code in any language, but by providing tutorials and examples that have glaring security issues and by not concentrating on teaching secure coding, PHP makes it that much worse. A great deal of useful code has been written on the PHP platform; it would be nice to find a way to keep that code coming while simultaneously making it more secure.

Index entries for this article
GuestArticles	Edge, Jake

The state of PHP security

Posted Dec 21, 2006 4:00 UTC (Thu) by elanthis (guest, #6227) [Link] (8 responses)

There are a few things PHP could do to improve security. Some of which are internal engine and module improvements (to avoid vulnerabilities in the C code), and some have to do with glaring problems in the language itself. Most of those have to do with much better automatic escaping.

(1) Register globals and magic quotes are still available. Completely remove them. I still see fresh code written today that depends on both as well as on PHP5 features.

(2) Database usage is still a hell, because you are expected to manually quote every input variable. This should be automatic. MDB2 explicitly removed the support for place-holders than PEAR::DB had (it can be added back in by asking for the "extension module"), and PDO also lacks these. The whole notion of forming SQL queries by concatenating strings and variables has to go.

(3) Scripting bugs are still way too common because PHP doesn't escape output by default. You have to explicitly do a call to htmlentities() on just about every echo statement or <?= construct. Compare this to the popular Smarty template system for PHP, which by default escapes all variable output, and you must instead explicitly mark output as being HTML safe if you don't want the escaping.

(4) For those shell escapes, which are common when doing web apps that integrate with various system bits, there's still no easy way to call a shell script without manually escaping all the input. Something that takes a list of arguments, instead of a string representing a command line, should be the defautl - perhaps _only_ - way of invoking other commands.

I've been working with PHP for some 7 years now, and it boggles my mind that these four issues are still not resolved. It's insulting, but my only conclusion is that the PHP designers are a bunch of security-clueless idiots who don't know how to design a language.

Don't even get me started on how the standard API is inconsistent, difficult to remember, and often surprising.

The only reason I'd tell people to stick with PHP is that there are no other mainstream, regularly-available web scripting languages that are any better. The few that exists just aren't available on most web hosts.

The state of PHP security

Posted Dec 21, 2006 19:04 UTC (Thu) by iabervon (subscriber, #722) [Link] (7 responses)

I still think the solution to SQL access is to remove support for using strings as SQL statements, and instead have a "SQL statement" type, with functions to append statement text (with it being an error to include any single quotes in this) and to append constants. This is easier to use and read than concatenating strings anyway, and can be implemented safely regardless of what the foolish users do.

The state of PHP security

Posted Dec 22, 2006 2:48 UTC (Fri) by denials (subscriber, #3413) [Link] (4 responses)

I still think the solution to SQL access is to remove support for using strings as SQL statements, and instead have a "SQL statement" type, with functions to append statement text (with it being an error to include any single quotes in this) and to append constants.

Sigh.

Every programming language uses strings for SQL statements. You can concatenate those strings and make mistakes in every language. The root of this particular problem, IMHO, goes back to MySQL's inability (until recently) to support placeholders. MySQL, you will recall, was the database most often paired up with PHP to enable beginning programmers to create dynamic Web applications. MySQL's lack of placeholders necessitated the interpolation of variables directly into SQL statements, or the concatenation of variables with SQL statement strings, in an unsafe manner. Top that off with the "user-friendly" but lax treatment of things like allowing you to quote-delimit integers (not legal in strict SQL) and you have a recipe for SQL injection attacks.

As an aside: single quotes are actually legal in SQL (usually escaped as ''), so making it an error would be even more foolish than creating an "SQL statement" type. SQL statements, like it or not, are made of strings.

The state of PHP security

Posted Dec 22, 2006 10:03 UTC (Fri) by kov (guest, #7423) [Link]

Every programming language uses strings for SQL statements. You can concatenate those strings and make mistakes in every language.

True. But many languages provide APIs that do _not_ use strings for SQL statements, and that are usually the recommended way of doing SQL.

The state of PHP security

Posted Dec 22, 2006 17:00 UTC (Fri) by iabervon (subscriber, #722) [Link] (2 responses)

Every programming language (with SQL bindings) does seem to use strings for SQL statements, and it's a design error in every one of them.

SQL string constants can have single quotes in them escaped as a sequence of two single quotes, but SQL statements can only have single quotes using weird other methods (for purposes like having a column named "don't", of course; none of the standard functions or keywords contain single quotes). And SQL statements can (and must) include single quotes around string constants, but I'm prohibiting writing string constants as statement text.

E.g., you'd have to write something like:

new Statement().cmd("SELECT uid FROM passwd WHERE password=").
                lit(password).cmd(" AND username=").lit(username)

And this would ensure that the two string literals are properly quoted and escaped. And the user can't do something like cmd("WHERE password='" + password + "'") because the single quotes in the command text are prohibited. And obviously cmd("WHERE password=").cmd(password) would never work, because the client-supplied password wouldn't get even the outer single quotes. So the correct way is the only way to get it to work at all, and you don't have any SQL insertion holes possible unless the language bindings get screwed up.

Of course, it's not necessary for the database to support placeholders in order for the language bindings to support substituted constants. The language bindings can substitute properly-handled constants, which would imply that any security flaws must be in the language bindings, which are exclusively written by people who ought to know better than to mess it up.

The state of PHP security

Posted Dec 25, 2006 4:39 UTC (Mon) by erich (guest, #7127) [Link] (1 responses)

Sorry, but that's just a hack to make users switch to a secure syntax.
And it especially prevents programmers who know about the security implications to make their code readable... e.g. by constructing queries in strings.

I used to have hardcoded statements such as 'WHERE email NOT LIKE "%@%"' and I'd sure prefer to keep them this way. Also note that with LIKE, you might need a different escaping (which eventually needs to escape %, too).
Having to use 'WHERE email NOT LIKE ?' and passing "%@%" as first parameter is fine with me, but don't force me to use that ugly pseduo-OOP syntax you suggested, with two different appends for the string buffer. Ugly!

P.S. sometimes you need quotes to be able to access certain tables or colum names. E.g. have you had a column named "like"? or "where"?

The state of PHP security

Posted Dec 25, 2006 6:08 UTC (Mon) by iabervon (subscriber, #722) [Link]

The company I was working for eventually ripped out all of the statements constructed in strings because they were too unreadable. It's fine if the query doesn't vary at all, but once you have any variability at all, either structural or with constants, it's more readable to have a smart buffer. Of course, the syntax should fit the language you're writing in (mine was Java, hence the StringBuffer method chain); maybe you'd rather

buffer = SQL("SELECT uid FROM passwd WHERE username=") + username +
  SQL(" AND password=") + password;

Incidentally, you're using entirely the wrong quotes. String constants have to be in single quotes (unless you're using old MySQL syntax), and column names can only be in double quotes (or, if you're using old MySQL, back tics). If you're using the same quotes for both string constants and column names that match keywords, you've got bigger problems than the library interfering (is "password" a constant or a column name?)

The state of PHP security

Posted Dec 26, 2006 12:49 UTC (Tue) by IkeTo (subscriber, #2122) [Link] (1 responses)

> I still think the solution to SQL access is to remove support for using
> strings as SQL statements, and instead have a "SQL statement" type, with
> functions to append statement text (with it being an error to include any
> single quotes in this) and to append constants.

I don't think so. There is no intrinsic problem of using strings as SQL statements. It is the same whether you write

handle.do_select("SELECT id, name FROM customers WHERE country='" + country + "'")

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country='" + country + "'")).

If your user don't know what's wrong with it, you can't expect them to do the right thing for it. If the syntax for doing things the secure way is harder than the syntax for doing things the insecure way, you will see lazy people doing the wrong things saying that they are only for the prototype and never correct it when the software is released.

The only answer is a combination of education and making correct things easier. Make the first example in the official database tutorial that needs a user-provided input to read handle.do_select("SELECT id, name FROM customers WHERE country=?", country), and tell learners that this is safe because even if country contains a single quote or semicolon it does the right thing to get them escaped. Build the library so that a single placeholder syntax is used for all different SQL implementations. As a bonus, teach them how to subvert programs that simply appends the user input to the SQL. Then doing it the secure way is easier than doing it the insecure way, and people actually feel insecure when they write insecurely. Then there will be no more problem of SQL injection.

The state of PHP security

Posted Dec 26, 2006 18:57 UTC (Tue) by iabervon (subscriber, #722) [Link]

My point is that doing

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country='" + country + "'"))

should always give a runtime error "Single quote in SQL statement". The only way to do this query should be something like

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country=") + country).

You'll note that this is easier than the insecure way (you don't have to know how to put a string in a SQL statement, or remember to close your single quotes or anything like that, and it's shorter anyway, unless your language happens to have operator overloading for strings and nothing else), and, additionally, the system prevents the insecure way from ever being executed, regardless of whether its input is malicious in a particular case or not. The slightly inconvenient case is where you'd be able to use a hard-coded constant embedded in your SQL if that were permitted; but hard-coded constants are a pain for further development anyway; some day your DBA will make you change them, and you'll be sad if they aren't split out into a single location with a logical name. (The only exception being patterns for LIKE, where you have to suffer through making your pattern a string constant instead of having it embedded in the SQL.)

The only sure way to educate people not to write insecure code is to make insecure code not work at all. The lazy people who do things the insecure way for the prototype will find that the prototype doesn't even run, so they'll go back and do it the secure way.

The state of PHP security

Posted Dec 21, 2006 9:45 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

One thing that would possibly help a bit would be tainting data, like perl can do. Thus even with register_globals on, the programmer couldn't accedently use tainted data in include() or eval(). It would also catch people concatentating strings to send to the database.

It doesn't help completely with SQL injection ofcouse, and not at all for cross-site scripting, but it would help catch some of the worst excesses.

The state of PHP security

Posted Dec 21, 2006 16:54 UTC (Thu) by alanjwylie (subscriber, #4794) [Link]

Wietse Venema, the well known hacker - author of Postfix, TCPWrapper,
SATAN and The Coroner's Toolkit - recently posted to the PHP developers'
mailing list proposing adding run-time taint support.

http://news.php.net/php.internals/26979

an easier to read threaded view of the discussion:
http://groups.google.com/group/mailing.www.php-dev/browse...

The state of PHP security

Posted Dec 22, 2006 8:43 UTC (Fri) by trickie (guest, #34077) [Link]

The problem is not that PHP 'encourages' bad security, but that there is a large body of PHP code out there that still have security mistakes everywhere, and those mistakes were introduced long ago. Most of the PHP code publicly available is for version 4, which is not taking advantage of alot of the work done recently to encourage best security practice.

If you are using the latest version of PHP (5.2.0) alot of the early config options and language *features* that can cause security issues, are gone, or set to a nicer default.

Things like PDO (with proper prepared statements, with emulation for rdbms that do not support them natively), the filter extension, and new differentiating between including remote files for execution and just opening remote files, provide an experienced developer with alot of tools to help secure their application.

Of course PHP is still easy to use, and there are still going to be alot of people who have no proper software engineering experience using it, with or without regard to security. Its a progamming langauage. You do with it what you want. I mean i can make the same data filtering mistakes some people make with perl, python or any other langauge.

Too bad Stefan is gone, his contributions to PHP were enormous. Thanks for your time Stefan.

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 22, 2006 16:19 UTC (Fri) by denials (subscriber, #3413) [Link] (7 responses)

Note that the author's resume, posted at http://www.edge2.net/, states that he has "20 years of system and application development experience using C and Perl", with the only reference to PHP being "2+ years of website backend development" which mentions PHP only in passing.

It is common for developers who are primarily experienced in one language to attack the limitations or insecurity of another programming language, when they do not have a good base of knowledge in that other programming language. Web site security scanners that check for a failure of the application to escape output have turned up plenty of Perl sites that will happily return an error message of "We're sorry, but the username %3Cscript%3E alert(%22CSS vulnerability%22)%3C/script%3E is not recognized" while decoding the escaped strings and displaying the nice little JavaScript alert box that, in more nefarious hands, can be used to develop a cross-site scripting vulnerability. Developers in glass programming languages should not throw stones...

PHP has often been attacked as being insecure by design, and the author has teased out some of the history of the development of the language in which the developers tried to balance PHP's low barrier of entry with reasonable default security. However, talking about the default settings in PHP 4, when PHP 5 has been available for a couple of years now with safer default setting, and when PHP 6 (which will drop some of those insecure options all together) is likely to see the light of day in 2007, is simply unfair.

Speaking of unfair, pointing to an interview with Rasmus from 2002 reflects poorly on the author's journalistic balance. One can point to many instances of Linus making a decision about the direction of Linux on a specific issue, then turning around a month or a year later and admitting that he was wrong. Yet we do not pillory Linus by focusing on his original decision and ignoring his changes of mind. As an example of Rasmus' change of mind, the PHP 6 planning meeting from November 2005 (which included Rasmus) concluded that PHP 6 would drop register_globals, magic_quotes, and safe_mode entirely. See http://www.php.net/~derick/meeting-notes.html for the details -- this is the top hit in Google for "php 6 plans", by the way. The author could have easily done a little more research to find out what direction PHP was truly heading in, and providing an updated description of Rasmus' stance on these issues today.

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 25, 2006 4:56 UTC (Mon) by erich (guest, #7127) [Link] (5 responses)

Sorry, but your post is typical - in lack of hard facts, you attack him because of his CV. Very lame, dude! Then next you go after perl - "see, the dinosaurs are extinct, too, so we can just die as well!".

And the author did pretty much state your opinion in his article, too: "PHP proponents tend to take a 'blame the user' approach that is reasonable in some ways, but fails to recognize some of the inherent issues with PHP itself" - there you go, fits you dead on.

"with reasonable default security"
ROFL. Don't tell me anybody during the design of PHP really thought about security. It's been about legacy compatibility mostly.

There is more stuff that's wrong with PHP. For example the way it's embedded in HTML, and actually encourages that. People should be offered an easy to use template language (preferrably one where they can edit the HTML with their favourite GUI editor, talking about easy-to-use...) and some variable mapping. Have a look at Kid, Genshi, TAL/METAL, XML::Template (also available for PHP).

Your comparison with perl is very unfair. Perl has been around for even longer than PHP, and it was NOT DESIGNED to be a web development language, but for writing regular applications. It was not designed for security on the web either (though tainted mode is a great feature; just that many people don't know how to use it, just like they don't stop using register_globals). It was designed for chewing texts quickly, with a really compact syntax.

Still, the typical Perl CGI has fewer security issues compared to a typical PHP script out there, so who is the "glass programming language".

/me uses Python for his stuff. Much easier to read than PHP hidden in HTML.

Ruby has some nice sandboxing concept, that sounds useful for secure web programming...

A comment to the meeting notes:
"this is a moot point as we need to have different contexts (SQL, output...) and this can not be checked without knowing the application."

Oh, and Perl doesn't have SQL?

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 27, 2006 19:38 UTC (Wed) by denials (subscriber, #3413) [Link] (4 responses)

I feel compelled to respond to your comment. In doing so, I hope to better illustrate why I was concerned about the article in the first place.

Sorry, but your post is typical - in lack of hard facts, you attack him because of his CV. Very lame, dude!

A CV is a record of someone's education and experience. The author's CV is probably the hardest set of facts I could use to evaluate his familiarity with the subject matter of his article. There was little evidence on his CV that he had much education in, experience with, or involvement with PHP; therefore, I called his credentials into question.

Then next you go after perl - "see, the dinosaurs are extinct, too, so we can just die as well!".

I used Perl because 1) it is the primary language that the author has experience with and 2) as an example of another popular language used to develop Web applications that suffer from the same security vulnerabilities that similar Web applications programmed in PHP suffer from -- but which does not get nearly as much publicity for those vulnerabilities as PHP applications do.

And the author did pretty much state your opinion in his article, too: "PHP proponents tend to take a 'blame the user' approach that is reasonable in some ways, but fails to recognize some of the inherent issues with PHP itself" - there you go, fits you dead on.

This was not the primary point of my comment. My point was that the author used a quote from 2002 and failed to consider the last four years of PHP development before drawing a damning conclusion from that quote. I provided a quote from the PHP 6 planning process in 2005 that demonstrates that the PHP developers actually have recognized some of the inherent issues with the language and that they plan on doing something about it.

comments skipped, in the interest of being "polite, respectful, and informative" as LWN requuests.

Still, the typical Perl CGI has fewer security issues compared to a typical PHP script out there, so who is the "glass programming language".

Can you point to some "hard facts" that prove your assertion, please?

In the end, I feel that this article was not up to LWN's normal journalistic standards. Stefan Esser's departure from the PHP development team would have been a good opportunity to discuss not only the (to me, at least) interesting and passionate personalities that form the core PHP development team, but also serve as a good jumping-off point to investigate the state of PHP security as it stands in the 5.2.x (current stable) and 6 (development) branches of the PHP language. There is an interesting debate going on right now on the PHP internals mailing list about the possible addition of taint support and its potential roles in PHP security, as well as the relation to the ext/filter support that was added in the PHP 5.2.0 release, and some insights from Rasmus into how Yahoo! plans to use a strict global filter for PHP applications. All of this information is publically available from the archives of the PHP internals mailing list.

The kind of article I have come to expect from LWN would have delved into the current and future state of PHP security, rather than relying on a more than four-year old quote as the sole insight into the state of mind of the PHP development team. I do hope that the author will consider this feedback in his future articles; I'm willing to entertain the possibility that this article was just a one-time lapse of taking the easy way out with a deadline leading up to the holidays.

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 27, 2006 20:26 UTC (Wed) by jake (editor, #205) [Link] (3 responses)

> There was little evidence on his CV that he had much education in, experience with, or involvement with PHP; therefore, I called his credentials into question.

I guess it isn't clear to me how much experience is required to comment on and have an opinion about PHP security. That being said, you may also wish to consider that 20+ years of developing software in any language is probably enough experience to rapidly understand a new one. I believe my knowledge of PHP is quite broad, but in the end, I don't think it matters to *report* on the language. There are tons of technical journalists who have a great deal less (or no) development experience than I do, but, at least in my opinion, that doesn't mean they cannot report on things and have opinions about them.

Your main problem with the article (other than getting your hackles up because you perceived an attack on PHP) seems to be my use of the 2002 interview. I did think about whether or not to use it. In the end, it seemed so completely mind-boggling to me that the creator of PHP could not see the issues with both register_globals and magic_quotes after *years* of exploits. I am quite glad to hear that he has changed his mind, but it was and is amazing that after mountains of evidence to the contrary, Rasmus still thought those were good features. I thought readers would find this interesting as well.

> I do hope that the author will consider this feedback in his future articles;

I read all the comments on my articles and will definitely consider what you have said. I don't think you make much in the way of substantive complaints about the article; you just wish it had been a different topic (i.e. future PHP security plans). That topic does sound like a good one, perhaps you should contact Jon and see if he is interested in having you write it. If not, I will certainly consider it for a topic down the road.

jake

Thanks for the response

Posted Dec 28, 2006 3:51 UTC (Thu) by denials (subscriber, #3413) [Link] (2 responses)

Thanks for the response, Jake. I can understand that you feel defensive about my comments; I comment because I care about LWN. I suspect that this is just a misstep for you and LWN; but that being said, I'll try to explain why I'm so concerned about what I'm concerned about.

I agree that twenty years of software development can help you get up to speed quickly with a new language's syntax. Understanding a language's syntax, though, does not replace the kind of research that technology journalists do to understand their subject matter before they present their opinions to a trusting audience. In this case, the subject matter is "PHP security", and you've nailed some of the historical design decisions that led to vulnerabilities. However, it is my opinion that you failed to accurately represent the state of PHP security.

My main problem with your article was not that you used an interview from 2002, but that you paraphrased Rasmus's quote from that ancient (by the world of technology measures) interview in an article called The state of PHP security without mentioning that the quote was from 2002. One suspects that most readers would be led into thinking that this statement represents the current state of PHP security:

It is an extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems to think should have been left on by default.

I agree that this was an interesting statement, but in the interests of fairness (particularly because you noted how "amazing" the statement was) you should have, at the very least, used the past tense and explicitly noted that the statement was from 2002. And it would have been both appropriate (for on online publication called the Linux Weekly News) and interesting to find out if Rasmus's thoughts on the matter might have changed in the last four or five years -- perhaps even get him to revisit his 2002 quote in that interview. This would have been a reasonable and decent thing to do. As the author of an article that attributed a "mind-boggling" position to Rasmus, you should not have had to hear it from me that he has since changed his mind. It was your duty to your readers to find that out and tell it to them.

You suggested that what I wanted was a different article. Again, I will agree: I wanted a better article, one that fulfilled the promise of the title by reflecting the state of PHP security. To do that, I suggest that you have to consider:

where PHP security was (well done)
where PHP security is (not so well done; I think everyone would agree that the proliferation of bad tutorials and poorly written applications that unfortunately have "php" in their name is a tough nut to crack, but you failed to mention the addition of the ext/filter module in 5.2.0 that has the potential to either significantly improve the security of PHP applications or become another misadventure in trying to automate security; actually, come to think of it, you missed all of the security changes in the 5.2.0 release notes from back on November 2nd, including disabling (by default) URLs in include, although you can be forgiven for missing the ongoing taint mode discussion as that just cropped up on Dec. 15th)
and where PHP security is going (not well done: nary a mention of the readily available PHP 6 plans)

I have no hackles to raise about attacks on PHP in particular. I have developed and maintained applications in C, Java, Perl, PHP, and Python, and have written articles and/or chapters of books about all of these languages, and have spoken at conferences about Perl, PHP, and Python. I'm not a one-trick PHP pony. Having a foot in all those worlds, I will admit that it gets tiresome watching PHP get slagged without substantiating claims simply because it's accepted practice in the unwritten hierarchy of programming languages, and your article did emit a whiff of that attitude. But I primarily care about fairness, balance, and the standards that LWN has set by example in the past. If I was forced to place this article on a journalist quality continuum between "slanderous fiction" on the one side and "shining model of balance and insight" on the other side, I would have to agree that I felt that this article fell more on the negative side of the continuum ("an attack on PHP" as you say) due to the failure to clearly state the date of Rasmus' statement, the failure to follow up with Rasmus or the PHP development team, and the general omission of significant developments in PHP security (whether by design or by lack of research).

I've been an LWN subscriber since 2003 because LWN has an excellent record of hitting the positive side of that journalistic quality continuum. As I said in a previous comment, I'm sure that the quality of this article was just a downward blip due to holiday schedule pressures.

Thanks for the response

Posted Dec 28, 2006 5:37 UTC (Thu) by jake (editor, #205) [Link] (1 responses)

Upon further reflection, the title, which I did suggest, is not an accurate representation of the contents.

PHP 5.2 and 6 are all well and good and I applaud the PHP team for whatever strides they have made security-wise. As I said, it would probably make a nice article. Unfortunately, many apps and hosting sites still only support earlier versions of PHP, some dating from 2002, perhaps. This is, of course, not the fault of the PHP team, but it might have been avoided by taking some of the steps you describe a bit earlier in the development of the language.

I get tired as well of reading SQL injection, XSS, remote file include and other vulnerabilities in PHP apps, in many cases written by people who are trying to get it right. Perhaps my weariness with all of that crept into the article more than it should have.

I appreciate your comments, thanks ...

jake

Thanks for the response

Posted Jan 4, 2007 9:40 UTC (Thu) by appie (guest, #34002) [Link]

With regard to SQL injections, if you don't use an abstraction layer and are using postgresql (applause! :-) be sure to use:
pg_query_params()
http://www.php.net/manual/en/function.pg-query-params.php
It's available since PHP5.1

And remember to revisit the excellent (!) online PHP manual plus comments every now and then to check for new and improved features.

Author's credentials: not enough knowledge about PHP's development?

Posted Dec 26, 2006 15:48 UTC (Tue) by tjc (guest, #137) [Link]

As an example of Rasmus' change of mind, the PHP 6 planning meeting from November 2005 (which included Rasmus) concluded that PHP 6 would drop register_globals, magic_quotes, and safe_mode entirely. See http://www.php.net/~derick/meeting-notes.html for the details

Very interesting -- thanks for the link.

Even good programmers can't write secure code with PHP

Posted Dec 25, 2006 19:12 UTC (Mon) by erich (guest, #7127) [Link]

... it is just too hard to get your code secure:

phpBB released another update with security fixes. They obviously are still not yet done with getting their application secure, but it just goes on and on with new vulnerabilities.

Now don't tell me PHP is easy to use, but even the phpBB coders are too stupid to use it properly?