Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
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 phpsec.org."
This discussion has been archived. No new comments can be posted.

PHP Security Consortium Launched More

PHP Security Consortium Launched

Comments Filter:
  • It's good to see more promotion of secure coding practices, especially with Web languages like PHP.

    • Re:Good (Score:2, Interesting)

      by blankslate ( 748549 )
      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.

      • Re:Good (Score:5, Interesting)

        by arkanes ( 521690 ) <(arkanes) (at) (gmail.com)> on Tuesday February 01, 2005 @05: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.

        • Re:Good (Score:4, Insightful)

          by blankslate ( 748549 ) on Tuesday February 01, 2005 @07: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 ..
          • Because there's no such thing as "security" when you're streaming files. Think about what you said - you need to have an mechanism for authentication, which is both secure and usable. You need to have a mechanism for identifying which files are accessible and which are not, and the user of your component needs to configure it correctly and with knowledge of what he's sharing. Think back a few years to all those people who shared entire hard drives on P2P apps, or who have web servers/file shares set up shar
            • i don't disagreee with anything you just said. That said, why not write a class / widget which: 1) provides a mechanism for authentication, which you can override with your own if desired 2) includes information about the need to store secured files in a private directory, and a configuration file which controls access to the private directory (requiring explicit addition with wildcards) Yes, as you say, the user will have to "configure it correctly and with knowledge of what he's sharing" - but I would
  • Though so far there's not a lot of content on the site (one article on CAPTCHAs, a bunch of links). It'd be nice to see them covering the most common problems, such as Cross-site scripting attacks, SQL Injection attacks and so on, which are prevalent on PHP/ASP/other CGI sites. I'm sure PHP-using Slashdot readers can help out?

  • Wow! (Score:5, Funny)

    by Anonymous Coward on Monday January 31, 2005 @10:28PM (#11536589)
    They must have offices next door to the MySQL Data Integrity Consortium and the Internet Explorer Web Standards Consortium.

  • Want to make PHP more secure? (Score:3, Insightful)

    by Anonymous Coward on Monday January 31, 2005 @10: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.

    • Re:Want to make PHP more secure? (Score:5, Informative)

      by shiflett ( 151538 ) on Monday January 31, 2005 @10:51PM (#11536762) Homepage
      Drop all insecure legacy features like "register globals".

      As mentioned here [phpsec.org], we recommend that register_globals be left disabled. It has been disabled by default in PHP since version 4.2.0.

      HTML ESCAPE BY DEFAULT.

      This is a poor approach. Data should be filtered on input and properly escaped for its particular purpose on output. Escaping data for one particular purpose on input requires developers to unescape it for any other use, and this unnecessary complexity poses a security risk. Properly educating users as to what functions are there to help properly escape data is our approach. For example, want to avoid XSS? Escape your (already filtered) data with htmlentities(). Want to avoid SQL injection? Use an escaping function specific to your database of choice such as mysql_escape_string().

      Then I'll start to take PHP seriously.

      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.

      • 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 sit

        • It's so unfair to compare PHP with Perl, C, C++. They are so disimilar, it's like comparing oranges and plastic.

          ASP is the only language worth comparing with PHP since they serve the same function.

          • I'm not comparing what these languages are designed to address as far as application, I'm talking about good programming habbits prevent nasty things that you can do in almost any language.

      • 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.

        Yes, true. However, there are also large companies that take very questionable ideas very seriously. The whole "It is good because large organization X uses it." idea no longer applies because large companies and websites, in general, tend to be run by idiots. (


      • Want to avoid SQL injection? Use an escaping function specific to your database of choice such as mysql_escape_string().

        No. Use a system that supports prepared statements (or which simulates the functionality by doing the proper quoting for you behind the scenes). If PHP cannot do this, drop it in favour of a non-toy language; there's many of them out there that will integrate as well (or better) with Apache.

        Come on, everyone! We've known the answer to this one for donkey's years!

    • Or, uh, just use Perl?

      *duck* :-)

      -Bill
      • And how exactly Perl helps you around these common pitfalls found in web-based applications?

        You have to filter input and escape output just the same way in Perl.

        You can shoot yourself in the foot with PHP as you can with C - it's not the programming languages fault people don't know how to write secure code, and these people are promoting safe practices, which is very nice and respectable.

        If you don't know how to write secure web applications from the ground up, you are better off with some "frameworks"
        • My original post was really just a joke, but are you serious?

          Think allow_url_fopen and register_globals?

          -Bill
          • You are correct in that those features are propably the 2 most widely security-hole causing things in php. register_globals is now off by default, which it should have been from the start. fopen-wrappers for urls are "shoot yourself in the foot" -thing, if you want similiar functionality in perl, you can propably get it from CPAN. My point is that it's not really the languages fault people are not competent enough to write secure code, and checking intput and sanitizing output must be done also in perl - th
      • Or, uh, just use Perl?

        *duck* :-)

        I want to program, not generate a simulation of line noise!

        *duck* :-)

    • Drop all insecure legacy features like "register globals".

      The only thing that makes "register globals" insecure is an incompetent programmer. I have lots of old production code that was written long ago that will break if register globals is removed.

      Exception handling is fine, as long as you can define what exactly is considered an exception. Currently, setting ERROR to ALL in PHP will cause PHP to throw errors just because you looked at your monitor funny.

      Isn't it ridiculous that you have to rememb
    • > HTML ESCAPE BY DEFAULT.

      how would I type :

      print('&nbsp;');

      ?

      more crazy quoting rules perchance ?

      printf("%s\n", email_address);

      doesn't html escape it's output, why do you think other languages should automatically do it ?

      what if I have header('Content-Type: text/plain');

      or header('Content-Type: image/jpeg');

      > fork and chroot each PHP script

      It is the job of the web server to decide how to handle its scripts. Not the scripting language. FYI My web server is *already* chrooted and I'd rather

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

    by Spoing ( 152917 ) on Tuesday February 01, 2005 @12: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.

    • Another gripe about PHP. Why do folks constantly reinvent the same thing? No or little borrowing. All customized.

      Plone products -- borrowing from Plone and other Plone Products with Plone borrowing from Zope and Zope borrowing from Python -- is just about an ideal example of how to strengthen multiple projects while still getting the narrowly focused service you want that can be tweaked at will. Others can come up with non-Plone examples that they favor, so don't take this as a PHP vs. Plone rant. It

      • Comment removed based on user account deletion

      • Another gripe about PHP. Why do folks constantly reinvent the same thing? No or little borrowing. All customized.

        Huh? [php.net]

        Plone products -- borrowing from Plone and other Plone Products with Plone borrowing from Zope and Zope borrowing from Python -- is just about an ideal example of how to strengthen multiple projects while still getting the narrowly focused service you want that can be tweaked at will. Others can come up with non-Plone examples that they favor, so don't take this as a PHP vs. Plone rant.

          1. Huh?

          Yep; it was a generalization. I'm mostly frustrated with the customization aspects. Grab some Wikis based on PHP and they look impressive. Try and customize, say, Twiki, and keep it in sync with the developers and get ready for problems. Very frustrating. The parts may be borrowed, though they don't work that way. All very implementation specific.

          1. About the absolutely worst software documentation I've ever seen in my life.

          With Plone, you can see what is possible...with Zope. With Zope, y

          • With Plone, you can see what is possible...with Zope. With Zope, you can see what is possible with Python.

            The problem here is that Plone is not a language; it is a CMS. And Zope is not a langauge; it is a framework that happens to be written in the language Python. Python otherwise shares the same problem as PHP: when you start a new project, you either have to find some existing code or reinvent the wheel. Zope minimizes this by providing a framework in which you can work and find a lot of the code you

      • Why do folks constantly reinvent the same thing? No or little borrowing. All customized.

        You know, I have to say that reuse is overrated, in any language you can name. I will only use someone else's code -- whether it's a single function or an entire project -- if it's well-documented and shows predictable, easily understood behavior. Very often it is easier to reinvent the wheel than to try to fit someone else's wheel onto the car you're building, especially if that wheel seems to be a good all-around w

      • Why do folks constantly reinvent the same thing? No or little borrowing. All customized.

        NIH syndrome knows no language, it's universal. PHP has PEAR [php.net] and the PHP Foundry on SourceForge [sourceforge.net], developers who don't check there for code to meet their needs before running off to write stuff deserve the pain.

        Plone borrowing from Zope and Zope borrowing from Python

        Plone, Zope, and Python are entirely different sorts of beasts. I'm not sure what your point is.

  • Too bad the only article contains a race condition (Score:3, Interesting)

    by Wizard of OS ( 111213 ) on Tuesday February 01, 2005 @07: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.
    • The only article if you don't count the security guide [phpsec.org].

      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).

      It doesn't always write the same one. Yes, two people could see the same one, but how is that a problem?
      • The code says:

        and:

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

        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
  • 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].

Slashdot Top Deals

"Virtual" means never knowing where your next byte is coming from.

Close