Live data from Hacker News

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

zdnet.com

51–60 of 71 posts

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

#51
post #7

Earlier quoted context omitted.

I really don't blame the author here, sure there was an issue with the sample code - but come on it was sample code. If someone is implementing user uploads they should really do the due diligence and understand what the sample code does. 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. Thi…

Not a good way to look at it. Sample code is equivalent to production code. It will be copied, verbatim, if it appears to work. Once it has the appearance of working, it isn’t looked at again. It doesn’t matter if you think people should be doing this or not. The only thing that matters is they will .

Exactly this.

For most developers there doesn't seem to be a differentiation between example code on a blog post and actual producation code.

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

#52
post #16
post #7

Earlier quoted context omitted.

I really don't blame the author here, sure there was an issue with the sample code - but come on it was sample code. If someone is implementing user uploads they should really do the due diligence and understand what the sample code does. 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. Thi…

I'm not going to throw stones either. But I would encourage developers to make their sample code robust. Especially as > many PHP users are hobbyists or come from a more traditional "webmaster" background I seem to remember a somewhat related problem with WordPress. The issue there was made worse by the fact the sample code was part of the default install and so available to anyone who knew the URL. Edit: A quick sea…

The simplicity of the sample code is a strong factor in deciding what library to use for a task.

If the 'hello world' example is hundreds of lines, then I imagine the effort of using this library to be a few days at least.

If the 'hello world' example is just 3 lines, then I can probably integrate this library into my service in 10 minutes.

Making the sample code more robust (handling errors, checking for legacy configs, etc.), makes it longer, which in turn puts off people like me.

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

#53
Haven't seen this sample code, but in general letting your users set the filename of anything on your server is a bad plan.

If the upload script just generated a random filename (046359905445.bin), and then stored the mime type, users filename, other metadata, etc. in a database, that would be a much better design.

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

#55
post #4

Author of jQuery File Upload here. The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component. To give you some context on how this could happen: - As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file - Over tim…

are other web servers vulnerable ? for example, wildfly jboss server,??

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

#56
post #27

Earlier quoted context omitted.

He's a former co-worker of mine, and is an awesome dude in many ways. His name really is Larry Cashdollar, born and raised. Sometimes I wrote his name as 'Larry $$' though.

Larry was also super helpful in identifying the underlying issue and very polite in his emails. Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;)

Thanks, :-)

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

#58
post #36
post #4

Author of jQuery File Upload here. The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component. To give you some context on how this could happen: - As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file - Over tim…

That's exactly what a security post-mortem should look like. - 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!

Thanks a lot!

By now I've also updated the project page with

- Security-related releases on top of the main page: https://github.com/blueimp/jQuery-File-Upload#%EF%B8%8F-secu...

- Security guidelines linked in various places on how to securely set up file uploads: https://github.com/blueimp/jQuery-File-Upload/blob/master/SE...

- A list of the fixed vulnerabilities with instructions on how to fix it for the recent critical one: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...

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

#59
post #41
post #34

Earlier quoted context omitted.

> Never allow all file types for upload by default, even if it is secure in your configuration 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…

Also known as "use a whitelist instead of a blacklist ".

Although I agree with you in a general sense, in this case there was no blacklist mistakenly used.

If the server is configured to serve uploaded files securely, it is feasible to allow all file types for upload (e.g. think of Amazon S3 or Google Cloud Storage).

However since there is no way to ensure that the server security settings to securely handle uploaded files are applied, limiting file uploads with a whitelist minimizes the attack vector sufficiently.

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

#60
post #50
post #4

Author of jQuery File Upload here. The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component. To give you some context on how this could happen: - As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file - Over tim…

There is no blame on you. There is no way you can provide a configuration that will be secure on every server. 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 fo…

Thanks!

I already got a helpful pull request for the main README.me that I've updated by now with

- Security-related releases on top of the main page: https://github.com/blueimp/jQuery-File-Upload#%EF%B8%8F-secu...

- Security guidelines linked in various places on how to securely set up file uploads: https://github.com/blueimp/jQuery-File-Upload/blob/master/SE...

- A list of the fixed vulnerabilities with instructions on how to fix it for the recent critical one: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...

The demo code was fixed as soon as I could confirm the report from Larry Cashdollar.

Post reply on HN