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

use Perl Log In

Log In

[ Create a new account ]

Journal of rafael (2125)

Monday December 11, 2006
06:43 AM

PHP security

[ #31879 ]
We all know that, due to the poor design of the language, security and PHP applications don't mix well, because PHP makes writing secure code difficult; apparently security doesn't mix well either with the mindset of the PHP core developers.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 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 --

    • Don't discount personality conflicts either. As with any technical community, there are some people who don't mix very well. (You can usually remove the word "technically" from the previous sentence.)

  • I find the last paragraph of his blog the most interesting:

    For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.

    Besides the other possible back-stories others have mentioned, it seems that they've falle

    • I would hope that problems with Perl would immediately be made public so we have a chance to deal with them. I think, however, that we probably have a more reponsive set of core developers who already do their business in public (i think, maybe I'm just not in the star chamber :)

      Well, besides perlbug and P5P there is no infrastructure to report security bugs... (and the last core security bug that was found was a printf format string vulnerability back in December 2005, which was promptly fixed.) There might be for some CPAN modules, but I'm not aware of that...

      • That's a very good point. What additional infrastructure is needed?
        • None, probably. If you built it, it would gather dust.

          I think the p5p mailing list is the best venue for reporting security problems. One doesn't have to be subscribed to post to it...