Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

PHP Programming Security

PHP Security Consortium Launched 64

Posted by timothy
from the floodgates dept.
Chris Shiflett writes "We're happy to announce the official launch of the PHP Security Consortium (PHPSC). Our mission is 'to promote secure programming practices within the PHP community through education and exposition while maintaining high ethical standards.' You can read the official press release or visit us at"
This discussion has been archived. No new comments can be posted.

PHP Security Consortium Launched

Comments Filter:
  • Re:Good (Score:2, Interesting)

    by blankslate (748549) on Monday January 31, 2005 @11:30PM (#11536601)
    Nice. It'd be good to see an audited set of widgets made available for say, secure database logins and file dissemination which we know to be approved by expert eyes.
  • by Wizard of OS (111213) on Tuesday February 01, 2005 @08:51AM (#11538931)
    (I also posted this on the CAPATCHA topic, but I think it's relevant here too).

    Too bad that that example on that site of 'an international group of PHP experts dedicated to promoting secure programming practices within the PHP community.' is flawed.

    It always writes to the same .jpg file, so two people requesting the page at the same time will see the same image (the last generated one).

    If these are the PHP experts on secure programming, I am now really worried.
  • by Wizard of OS (111213) on Tuesday February 01, 2005 @09:17AM (#11539077)
    The code says:


    $image = $captcha->getCAPTCHAAsJPEG();
    $handle = fopen('captcha.jpg', 'w');
    fwrite($handle, $image);

    So, assume this happens:
    - Client A requests the site
    - Client B requests the site
    - PHP engine process request for A: generates a random string 'abcde' and creates the captcha.jpg for this 'abcde'
    - PHP engine process request for B: generates a random string 'fghij' and creates the captcha.jpg for this 'fghij'
    - Due to some network lag (200ms), A will now request 'captcha.jpg'

    A will see 'fghij', but the session for A will have 'abcde' set. This means that A cannot validate himself.

    The problem here is ofcourse that the file is always the same: if you would use a PHP file that generates the images for a request (based on the sessionid from a cookie), you would be safe.

  • Re:Good (Score:5, Interesting)

    by arkanes (521690) <> on Tuesday February 01, 2005 @06:55PM (#11545723) Homepage
    This attitude is in no small part responsible for the generally terrible security of web-based applications. Security is *not* a set of "audited widgets". You have to know what to do and what not to do - there's no magic widget that is going to secure your application. You *can't* write a general purpose, secure widget for exposing files over the internet without the end developer knowing what they're doing.

Simplicity does not precede complexity, but follows it.