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

Good

[LukaFox]

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

Re:Good

[blankslate]

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

[Anonymous Coward]

Isn't that what PEAR is?

Re:Good

[Anonymous Coward]

woot! I got fp!

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

Re:Good

[arkanes]

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 sharing their entire machine. The security implications of exposing files have very little to do with the actual mechanisms of sharing files, it's the meta-information that's important and thats is (and must be) in the hands of the end user.

Writing secure applications in a hostile environment is hard. There's no silver bullet, and PHP is especially egregious with it's history of insecure library functions and the encouragement of insecure programming (slowly getting better, but the typical PHP application is still a morass of SQL injection and data exposure vulnerabilities). The correct answer is education, and language/library changes to *discourage* the sort of insecure programming that people do, not giving an illusion of security through "secure widgets". A good start might be a functional database interface that doesn't permit the execution of arbitrary strings as SQL.

Re:Good

[blankslate]

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 put it to you that knowing what you want to share is more common than understanding all the other implications in coding a secure file streamer - just to use this as an example. In general I would think the availability of such a repository would increase security even if nobody used it, merely by pointing out the necessity of thinking about security (and the issues at hand) in circumstances where some programmers might otherwise fail to notice the need. Also, if the group were to lobby the PHP authors themselves to make changes to the core language / libraries as you suggest it could only help matters.

Good to see

[Atrax]

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?

Re:Good to see

[shiflett]

I guess you missed the PHP Security Guide?

:-)

Re:Good to see

[Atrax]

Sure, but it's not bite-sized, which is far more digestible - there should be stuff in the 'articles' section.

Re:Good to see

[shiflett]

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

Re:Good to see

[Atrax]

spose you've got a point. I just thought it might be nice to have it all covered in one place rather than shooting off to external sites. As long as it has the desired effect....

Languages with a short initiation period ...

[GNUALMAFUERTE]

Like, for example, PHP or Perl, are a good thing for startes, since they let them understand what coding is all about, and to experience the pleasure of programming. But they are also dangerous because they make it ease for the uninitiated to shoot their foot, in C, it's even easier to shoot yourself in the foot, but you won't go very far with no experience and limited knowledge, so, you will shoot your foot with a simple curses based agenda, and not with an online CMS, with PHP or even Perl, unexperienced people can create large projects, and in those cases, they can blow off the entire house and not just their foot.
It's good to see some initiative to prevent these.

Just my 2 cents.

ALMAFUERTE

Re:Languages with a short initiation period ...

[Anonymous Coward]

Due to the fact that 99.999% of PHP/Perl programmers are web designers who haven't got a flippin' clue about things like security and performance, I refuse to use any code on my site if I didn't write it myself. I almost feel bad when I see a site with interesting content running postnuke/phpnuke/phpbb/drupal/etc., because odds are, they won't last long.

Thankyou captain obvious

[Anonymous Coward]

I suppose that next time a story about a new Microsoft Windows exploit is posted, you will say "It's not good to see such little promotion of secure coding practeces, especially with popular Operating Systems like Microsoft Windows" ?

Somebody mod the parent redundant, please?

Wow!

[Anonymous Coward]

They must have offices next door to the MySQL Data Integrity Consortium and the Internet Explorer Web Standards Consortium.

Re:Wow!

[Anonymous Coward]

I think because
because this page is not valid xhtml

http://validator.w3.org/check?uri=http%3A%2F%2Fp hp sec.org

and because both mysql and php caused the appearing of a worm recently.

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:Want to make PHP more secure?

[Anonymous Coward]

GLAMP can be configured in a secure way, but most default configurations are _NOT_.

A Tuned Slackware + Latest Stable Kernel compiled on site + Latest Stable Apache well configured and with file permissions well seted on the webroot + Stable MySQL with TCP Conections disallowed + Compiled on site latest PHP with tuned php.ini, is one thing, but that requires knowledge and dedication, and the most common setup you will see will be Interland server with default, never updated redhat 9 installation.

This is a fact, but that doesn't justify doing things the Pascal way.

GNUALMAFUERTE

Re:Want to make PHP more secure?

[Saeed al-Sahaf]

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.

Re:Want to make PHP more secure?

[Anonymous Coward]

Languages with a short initiation period, like, for example, PHP or Perl, are a good thing for startes, since they let them understand what coding is all about, and to experience the pleasure of programming. But they are also dangerous because they make it ease for the uninitiated to shoot their foot.

In C, it's even easier to shoot yourself in the foot, but you won't go very far with no experience and limited knowledge, so, you will shoot your foot with a simple curses based agenda, and not with an online CMS, with PHP or even Perl, unexperienced people can create large projects, and in those cases, they can blow off the entire house and not just their foot. Hilary Swank's character is rendered paraplegic in a fight, and Frankie hesitates before helping her commit suicide. It's good to see some initiative to prevent these.

Re:Want to make PHP more secure?

[Anonymous Coward]

register_globals be left disabled

If a feature should be disabled, why is it even *present*?

This is a poor approach

If you are outputting HTML, your content should be HTML-escaped. XSLT for instance will do this by default so the output is well-formed XML.

You must see the constant XSS vulnerabilities in PHP (and other) apps. Why does everyone get this wrong?

Look at this code:

<?= htmlentities($first_name) ?>
<?= htmlentities($last_name) ?>
<?= htmlentities($address1) ?>
<?= htmlentities($address2) ?>
<?= $html_table ?>

Now look at this (inventing some syntax where "=" HTML-escapes and "!" doesn't):

<?= $first_name ?> <?= $last_name ?>
<?= $address1 ?>
<?= $address2 ?>
<?! $html_table ?>

Which is the programmer more likely to type under pressure of a deadline?

If I make a mistake and escape when I really want to to output HTML tags, I will see it immediately, because I will see the tags. However, if I make a mistake and not escape, I have created a hole. Maybe my malicious customer will inject HTML that hides my table elements and inserts his own that says "order paid in full". Maybe I'll allow XSS. Maybe I won't know until I read it on bugtraq.

I see this ALL the time in PHP (and other) apps. Programmers do what's easiest, no matter what you tell them. They are already busy. Telling programmers to work harder is not the right solution.

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.

If you don't want unnecessary complexity in PHP, eliminate the php.ini file. Lighten the syntax. Make htmlentities() a little easier to type.

Properly educating users as to what functions are there to help properly escape data is our approach.

Uh huh. Most of the HTML-producing PHP code I audit is written by non-programmers who don't even know what a "function" is.

I see unescaped HTML everywhere. This is clearly a problem that needs to be solved. I'm not talking about SQL injection. This usually goes through a layer of code that escapes automatically. However the template mechanism in PHP *is* the layer that's supposed to be doing the escaping automatically. And it doesn't.

PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites

How does that make it more secure?

Re:Want to make PHP more secure?

[superpulpsicle]

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.

Re:Want to make PHP more secure?

[wdr1]

Or, uh, just use Perl?

*duck* :-)

-Bill

Re:Want to make PHP more secure?

[Dark Lord Seth]

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. ( Both on technical and economical level )

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. Give courses all over the world that go in-depth regarding these matters. 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.

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

Re:Want to make PHP more secure?

[Anonymous Coward]

PHP and Perl are far more alike than ASP is with either. Even the syntax is more similar than most people admit, with the exception of some "magic" operators in Perl that can make it less verbose (or more confusing, depending on your perspective).

PHP and Perl are also well ahead of ASP by virtue of the fact that they function very well with Apache (mod_php and mod_perl, respectively). Most ASP shops run IIS. Need I say more?

Re:Want to make PHP more secure?

[Anonymous Coward]

Look at this code:

<?= htmlentities($first_name) ?>
<?= htmlentities($last_name) ?>
<?= htmlentities($address1) ?>
<?= htmlentities($address2) ?>
<?= $html_table ?>

Now look at this (inventing some syntax where "=" HTML-escapes and "!" doesn't):

<?= $first_name ?>
<?= $last_name ?>
<?= $address1 ?>
<?= $address2 ?>
<?! $html_table ?>

Which is the programmer more likely to type under pressure of a deadline?

I know you're trying to slant this question, but I honestly can't tell which one you want people to choose. :-) To me, the first is much clearer, because the name of the function is more descriptive than a magic operator. It also gives a developer something to look up (htmlentities) if looking at someone else's code. You can't search Google very well for cryptic operators.

Of course, if you like the second example better, it probably just means you should use Perl rather than PHP. Both are excellent platforms for web application development. I don't understand what point you're trying to make, though.

How does that make it more secure?

It doesn't. Did you not notice that he was replying to something? Reading comprehension is a wonderful skill.

Re:Want to make PHP more secure?

[Anonymous Coward]

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

Re:Want to make PHP more secure?

[golgotha007]

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 remember to HTML escape output??? All you have to do is forget one spot, and congratulations, your app is on bugtraq.

Your entire post says this to me: "I am an incompetent programmer. I need a language that holds my hand 24/7."

I recommend you stay away from PHP and look at other hand-holding languages (anything from MS should suffice).

Re:Want to make PHP more secure?

[DrSkwid]

If you think either of those approaches is appropriate you are a fool.

Using the <? php ?> some html <? php ?> approach is garbage

$h = new html();

$h->append($firstname, array('filter', 'htmlentities');
$h->append($last_name, array('filter', 'htmlentities');
$h->append($last_name, array('filter', 'htmlentities');
$h->append($address1, array('filter', 'htmlentities');
$h->append($address2, array('filter', 'htmlentities');
$h->append($html_table);

$h->output();

though the last part is more likely to be something like (depending on the data)

$h->open_table();
$h->add_row($cell1, $cell2);
$h->close_table();

Re:Want to make PHP more secure?

[DrSkwid]

> 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 not have the PHP authors introducing some extra security model of their own thanks.

Re:Want to make PHP more secure?

[zyzko]

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" that do the sanity-checking for you. Oh, wait, those contain bugs too...

-Kari

Re:Want to make PHP more secure?

[Saeed al-Sahaf]

Heretic. Heretic. Heretic. Cough, cough, HERETIC. NOBODY expects the Spanish Inquisition! Our chief weapon is surprise...surprise and fear...fear and surprise.... Our two weapons are fear and surprise...and ruthless efficiency.... Our *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope.... Our *four*...no... *Amongst* our weapons.... Amongst our weaponry...are such elements as fear, surprise.... I'll come in again.

Re:Want to make PHP more secure?

[Mr. Slippery]

Or, uh, just use Perl?

*duck* :-)

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

*duck* :-)

Re:Want to make PHP more secure?

[dkf]

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!

Re:Want to make PHP more secure?

[Anonymous Coward]

Prepared statements are good, and PHP does support them, but it's very wrong of you to suggest that escaping data is wrong.

Herein lies the problem with security education these days. Too many people like you don't know what they're talking about but act authoritative when they speak. There's plenty of misinformation going around, and I'm glad to see this group doing something about it.

Re:Want to make PHP more secure?

[Anonymous Coward]

many languages suffer from the atractive to retards problem.

if retards like your language then your language gets a bad reputation PERIOD.

Re:Want to make PHP more secure?

[wdr1]

My original post was really just a joke, but are you serious?

Think allow_url_fopen and register_globals?

-Bill

Re:Want to make PHP more secure?

[zyzko]

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 - that's the main problem with fopen_url -wrappers also.

It might be good to turn that off by default as well (I do turn it off in every server installation where I allow customer-made code to run).

-ka

Glad to see it...

[Spoing]

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.

Re:Glad to see it...

[Spoing]

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's a world vs. PHP rant! :}

Re:Glad to see it...

[digitalchinky]

I've borrowed loads of PHP stuff, though all of that code needs to be vetted, contemplated, modified, and jumped on to fit the hole it needs to fill.

I'm no expert, though I think this is a problem not just with PHP, but most languages. Perl is a good example for me. There are literally thousands of websites offering code snippets, some of it works, lots of it is obscure and undocumented. (Java is worse)

It's hard to sort through the noise at the best of times.

Where do you look, and is it safe to use? So I rebuild the tired old wheel, or spend just as long looking through someone elses code. Makes little difference. Doesn't mean you can't pick up handy tips along the way.

Re:Glad to see it...

[Khazunga]

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

Huh?

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's a world vs. PHP rant! :}

Oh, Plone is great if you just want to quickly deploy a CMS. It's H-E-L-L if you need to develop on top of it. About the absolutely worst software documentation I've ever seen in my life.

Re:Glad to see it...

[Spoing]

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, you can see what is possible with Python. If you need to cusomize something, you can always reach back down the stack to the part you do understand/find docs for. Remove what you do not want. Add what is missing. That said, I'm not holding up Plone as perfection as clearly it is not.

I'm a very big advocate of not reinventing the wheel. PHP apps tend to rehash much of the same things for each and every implementation. If the code for an implementation of one app is 90% of what you need, why build it from the ground up?

Re:Glad to see it...

[benramsey]

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 already need -- the wheel is already there.

There are many, many PHP frameworks out there that try to fill this need. The trouble is that there isn't a single PHP framework that has achieved the same level of notoriety as Zope. However, more and more people are using PEAR [pear.php.net] as a framework, and the beauty of PEAR is that you don't have to use the entire framework in one installation; you can pick and choose.

So, people in the PHP community are working to solve the wheel reinventing problem; it's just that many people either don't know about it or don't want to learn to use the existing frameworks.

Re:Glad to see it...

[Daniel Dvorkin]

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 wheel, but in fact shows a nasty tendency to come off when driving between 63 and 71 mph while bearing slightly to the left with a northwest wind under a waning quarter moon. On Tuesdays.

Re:Glad to see it...

[Mr. Slippery]

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 and the PHP Foundry on SourceForge, 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.

Re:Glad to see it...

[Spoing]

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

Consider it a thought experiment.

hehe bugs

[DrSkwid]

it should be array('filter'=>'htmlentities'));

Too bad the only article contains a race condition

[Wizard of OS]

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

Re:Too bad the only article contains a race condit

[thenextpresident]

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?

Re:Too bad the only article contains a race condit

[Wizard of OS]

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'

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:Too bad the only article contains a race condit

[Wizard of OS]

Aaah .. stupid me. The first line of code should be:

<img src="captcha.jpg" /> ... i did have 'Plain old Text' enabled when posting, well, nevermind.

You misunderstand me.

[Saeed al-Sahaf]

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.

filtered on input

[brlewis]

Your example shows filtering on output. Which part of "filtered on input" did you not understand? If you accept input, you need to filter input. Telling programmers to work harder if they are not filtering input is the right approach. If PHP had imitated the BRL define-input syntax it would be easier. Easy or not, it has to be done.

not necessarily

[brlewis]

If the language makes it easy to filter input, and if you teach about filtering input in the same place you teach about accepting input, then security problems from newbies can be dramatically lessened.

Re:Too bad the only article contains a race condit

[Anonymous Coward]

It always writes to the same .jpg file

Only if you use the same name every time, which the article does not say to do. So, you're trying to belittle the article based on your own screwup. Classic.

Coding Standards In General

[cyberscribe]

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, I am considering writing an article about this for the next issue of IPM.

Re:Too bad the only article contains a race condit

[lachlan76]

Ok, so they didn't plan it too well...going by IP would have been a better idea. But it was secure, wasn't it?

Re:Too bad the only article contains a race condit

[dkf]

going by IP would have been a better idea

Not really. At times in the past I've been behind a firewall that put over 100k people effectively on the same IP address (or a small pool of IP addrs). Thankfully that time is past now, but if you think that an IP addr identifies a unique machine, you're sorely wrong. The right answer is to go by session (identified by cookies, which web proxies usually handle right) and not commit any temporary files (like CAPTCHAs) to disk at all.