Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

PHP security 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I have to admit that I'm very curious as to the backstory here. I hope that it's not a simple matter of core PHP people just not being overly concerned about security. It could be something akin to the MS situation where MS is in the terrible position of having to ensure that patches work on hundreds, if not thousands, of configurations (different hardware, different OSs, different patch levels, different software installed, etc.) Somehow, though, I suspect the worst :(

    • Reading more articles in this blog reveals what the main concern of the author -- that the PHP community tends to blame applications written in PHP for the poor security, but usually rejects critics on the language and its implementation.

      As somebody having some experience of language design, I can see three kinds of problems. The first one, also the simplest, is applications written with no clue about security. For example, a web form to send email, where the recipient is coded into an hidden input field -- you could use it to spam people. (Hi, Matt's script archive.)

      Secondly, bugs with the implementation of the language. For example, buffer overflows in the interpreter, etc. leading to actions not intended by the language. Apparently, due to social tensions between the PHP and the hardened-PHP projects, those bugs might remain unfixed for months, or bug reports ignored by the PHP team, although they're affected. Actually that's what the blog guy asserts [php-security.org].

      Third, security features in the design of the language itself. A recent example with perl is my addition of a new check: when perl is run under taint mode, printf() and sprintf() will now reject any tainted format argument. (Other vulnerabilities have been fixed in printf format strings, and patches quickly made available for vendors to apply; but those were actual bugs.) There is more in perl's security than the sole taint mode; but in general perl and perl modules avoid to make simple operations ridiculously simple for programmers, like importing values from the environment as globals, or allowing to use modules whose path is given by an URL (or worse [php-security.org]).

      So, I think I suspect the worse too...

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.