Zero-day in jQuery plugin sample code exploited for at least three years

But everything else can be avoided with a whitelist of acceptable types by default.

To be honest I'm not really that surprised that the vulnerability stayed hidden for so long; many PHP users are hobbyists or come from a more traditional "webmaster" background. This is not to say that there aren't good PHP programmers, just that there is a large group of novices.

For what it's worth, you'll find lots of people disable support for .htaccess for performance reasons.

It's probably less of an issue these days, but if you support .htaccess files, apache reads the .htaccess file for the current directory, and those for every parent directory, and it happens on every single access.

So for example someone accessing http://foo.bar.com/thing/goes/here would cause the webserver to check for and read /thing/goes/.htaccess, /thing/.htaccess and /.htaccess. If you imagine you've done the sensible thing and got your content nicely split out, you can probably see how that can hurt performance. *nix OSs will be smart and cache the content etc. but you're still wasting time on every access making sys calls.

If you put the access rules in the apache config file, everything is set-up at initialisation time and it never has to make further checks.

The general form - never use default-allow - should be used in most situations where set of possible inputs cannot be exhaustively enumerated. In most situations, you cannot enumerate badness[1]. Instead of trying to define valid input by specifying it's inverse, it's far simpler (and safer) to use default-deny and specify valid input directly.

[1] http://www.ranum.com/security/computer_security/editorials/d...

- What went wrong

- Why did it go wrong

- What can be done to ensure this doesn't happen again

Everyone makes mistakes once in a while, the key is learning from them.

Well done!

My recommendation: add a big warning message that there is at least one known security hole and many unknown ones in the server code and it is up to the just to secure their server properly.

Then fix the demo code but leave the warning there.

It's always up to the developers to check the system they build for security problems. They could use the best frameworks in the world and copy thoro reviewed example code. The end result might still have huge security problems.

His name really is Larry Cashdollar, born and raised. Sometimes I wrote his name as 'Larry $$' though.

This is answered in the plug-in author's thorough note, posted a couple hours before you posted this.

The issue is not in the front-end jQuery library, despite the title.

I think one of the reasons nobody reported this earlier was that people simply assumed that .htaccess support was the default - Larry Cashdollar, the security researcher, also confirmed this: https://news.ycombinator.com/item?id=18271880

But although the title is somewhat click-bait, I still think this counts as a vulnerability in my project, since there is a possible combination of default Apache setting and default project files that is exploitable.

However I wish Apache would have changed their default config in a way that would have signalled an error if an .htaccess file is present but not applied.

Something that HA user fulafel also pointed out here: https://news.ycombinator.com/item?id=18272407

However the PHP code was written as easy-to-use sample code and I did not want to introduce a database as dependency and keeping the sanitized filename plus extension keeps the meta information intact.

If I had provided better information about how to securely configure the Webserver to allow all file types for upload, using the original - but sanitized - filenames would not be an issue.

Don't you think maybe he's heard this a few times already?

We detached this comment from https://news.ycombinator.com/item?id=18271880 and marked it off-topic.