6 ms·

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

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 time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production - I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured. - Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQuery-File-Upload/commit/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1 https://github.com/blueimp/jQuery-File-Upload/commit/13931c7... - The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it - The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQuery-File-Upload/pull/3381 https://github.com/blueimp/jQuery-File-Upload/pull/3381 Looking back, there are a couple of things that I should have done differently: - Move out the server-side components into separate repositories - Inform users better about file upload security - see https://github.com/blueimp/jQuery-File-Upload/wiki/Security https://github.com/blueimp/jQuery-File-Upload/wiki/Security - Never assume people actually read information about security - Never rely on .htaccess for security configurations in Apache - Make sure that published code is secure in all default configurations - Never allow all file types for upload by default, even if it is secure in your configuration - Recommend users to not upload files in the same root as their executable web application - Always follow security best practices, even if it makes setup for users more difficult I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other. Bonus info: The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQuery-File-Upload/commit/41750323a464e848856dc4c5c940663498beb74a https://github.com/blueimp/jQuery-File-Upload/commit/4175032... The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8c3e3b1e8e336678d2899facd5bcdb589f https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8...

aw3c2 8y ago
Don't beat yourself up. Your response shown here is insightful and reasonable. Well done!
- blueimp 8y ago
  Thanks a lot!
wolco 8y ago
Relying on apache version specific defaults is always the wrong approach. But everything else can be avoided with a whitelist of acceptable types by default.
willeh 8y ago
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. This is not to say that there aren't good PHP programmers, just that there is a large group of novices.
- ChrisSD 8y ago
  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 search shows I was thinking of an XSS attack. It was due to some bad example code in the default theme folder, which is by default publicly accessible even if not used. https://arstechnica.com/information-technology/2015/05/actively-exploited-wordpress-bug-puts-millions-of-sites-at-risk/ https://arstechnica.com/information-technology/2015/05/activ...
  - 8y ago

aw3c2 8y ago

Don't beat yourself up. Your response shown here is insightful and reasonable. Well done!

blueimp 8y ago
Thanks a lot!

wolco 8y ago

Relying on apache version specific defaults is always the wrong approach. But everything else can be avoided with a whitelist of acceptable types by default.

willeh 8y ago

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. This is not to say that there aren't good PHP programmers, just that there is a large group of novices.

ChrisSD 8y ago
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 search shows I was thinking of an XSS attack. It was due to some bad example code in the default theme folder, which is by default publicly accessible even if not used. https://arstechnica.com/information-technology/2015/05/actively-exploited-wordpress-bug-puts-millions-of-sites-at-risk/ https://arstechnica.com/information-technology/2015/05/activ...
- 8y ago