Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
PHP Programming Security

PHP Security Consortium Launched 64

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 phpsec.org."
This discussion has been archived. No new comments can be posted.

PHP Security Consortium Launched

Comments Filter:
  • by Anonymous Coward on Monday January 31, 2005 @11:33PM (#11536631)
    Drop all insecure legacy features like "register globals".

    Use exception handling from top to bottom. Don't allow an error or return value to go unchecked.

    Run code in some kind of sandbox by default. Example: fork and chroot each PHP script. Safe mode isn't good enough.

    HTML ESCAPE BY DEFAULT. Use a separate set of tags for un-escaped output. Isn't it ridiculous that you have to remember to HTML escape output??? All you have to do is forget one spot, and congratulations, your app is on bugtraq.

    Then I'll start to take PHP seriously.

    As long as PHP caters to the bottom 95% ("but if we change that, people will get confused"). I'll look elsewhere.
  • by Saeed al-Sahaf ( 665390 ) on Tuesday February 01, 2005 @12:34AM (#11537039) Homepage
    We are not an advocacy group. Our purpose is to promote secure programming practices within the PHP community, not promote PHP to other groups. PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites.

    This will fall on deaf ears here. This is a Perl Zone. Reason with respect to PHP does not work here, because people here fear php. And that's a shame because as you say, PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites. Those who discount PHP may find themselves being passed over for some very good jobs on very tasty projects.

    But what's funny is that many of the "problems" that people here have with PHP are present in their preferred language, Perl, C, C++, whatever. The solution is understanding the language you are working in, whatever it is, and using good programming habits.

  • Glad to see it... (Score:3, Insightful)

    by Spoing ( 152917 ) on Tuesday February 01, 2005 @01:03AM (#11537201) Homepage
    PHP web apps tend to have poor default security, and some are a real pain to customize because they are fragile beyond the configuration that the main developers use. Fragility alone is a potential security problem let alone a teeth gnashing exercise in paitience.

    I realize that this is a huge generalization. Don't get me wrong; I don't reject a program outright if I find that it was created with PHP. PHP does, though, raise an eyebrow.

    All things being equal, I do reject a PHP app quicker than a non-PHP app if it shows a similar number of questionable or just flat out poor security defaults or is designed with little attention to security. It's often harder to deal with and keep up to date as the original branch of the app is updated -- raising the frustration as time goes on.

  • by cyberscribe ( 756897 ) on Tuesday February 01, 2005 @03:33PM (#11543310) Homepage
    It is so refreshing to see these issue being dealt with head-on. The larger issue to me, however, is that PHP more than any other language these days is begging for coding standards and "best practices" -- of which security is an important part. As I mentioned in my blog [robertpeake.com], I am considering writing an article about this for the next issue of IPM [php-mag.net].
  • Re:Good (Score:4, Insightful)

    by blankslate ( 748549 ) on Tuesday February 01, 2005 @08:22PM (#11546427)
    So what do you want? People who don't know how to write secure code are writing *insecure* code with PHP. Should they
    a) write crap code themselves, or
    b) use tested and audited code, save themselves some time and get to see how it should be done in the process.

    And while there is no 'magic widget' that will fix your whole app, it's definitely possible to create a widget which will handle the login properly (probably where most SQL injection attacks occur), perhaps force a sensible password policy and maybe some code to test for some common security flaws (whether in code or against a live server).

    And - WHY can't you create a general purpose secure file streamer? I'm curious ... seems to me if you have configuration options for the private folder and a callout to a user defined function to check credentials (ok, so they might need to sorta understand this), it wouldn't be too hard ..

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...