Slashdot Mirror

Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.

There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.

As BP says, it's a start.

PHP's ease of use and flexibility do make for a dangerous combination. There's no arguing that.

I'm not so sure that the answer lies in the interpreter, although I'm open to the idea. In the meantime, the PHP Security Consortium is an effort to help educate the community about secure programming practices (among other things).

I also try to do my part (in addition to my work with the PHPSC) by providing free articles, giving various talks (including the PHP Security Briefing), and writing Essential PHP Security. Education might not be the only answer, but I think it helps.

So, you're right that there is a bit of a problem, but some of us are trying to help.

The only article if you don't count the security guide.

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?

Give us some free and good tutorials online as to how to secure PHP code. Show us some old exploits and how to avoid falling in the same traps like that again.

http://phpsec.org/projects/guide/
http://phpsec.org/library/

Give courses all over the world that go in-depth regarding these matters.

I'm not sure if this counts, but Zend offers online training, and one of their advanced courses is Securing PHP Code.

I love working with PHP but the constant screwing around with globals, superglobals and what-have-ye-not really make security a nightmare on it.

There are two scopes. If that's too many, programming might just not be your thing.

Those among us who are serious about PHP want actions, not propaganda.

This is in reply to the bit you quoted? If so, perhaps this will help:

http://www.answers.com/propaganda

Give us some free and good tutorials online as to how to secure PHP code. Show us some old exploits and how to avoid falling in the same traps like that again.

http://phpsec.org/projects/guide/
http://phpsec.org/library/

Give courses all over the world that go in-depth regarding these matters.

I'm not sure if this counts, but Zend offers online training, and one of their advanced courses is Securing PHP Code.

I love working with PHP but the constant screwing around with globals, superglobals and what-have-ye-not really make security a nightmare on it.

There are two scopes. If that's too many, programming might just not be your thing.

Those among us who are serious about PHP want actions, not propaganda.

This is in reply to the bit you quoted? If so, perhaps this will help:

http://www.answers.com/propaganda

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.

There are links in the Library that point to existing resources like that.

I guess you missed the PHP Security Guide?

:-)

PHP developers might find this article useful:

http://phpsec.org/articles/2005/text-captcha.html