PHP Security Consortium Launched

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

Comments

Re:Good to see

[shiflett]

I guess you missed the PHP Security Guide?

:-)

Wow!

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[shiflett]

Drop all insecure legacy features like "register globals".

As mentioned here, 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.

Re:Good

[arkanes]

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

[blankslate]

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