6 ms·

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 the

by 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...
- blueimp 8y ago
  I agree, the sample code should have been secure by default (with all web server configurations) because it's guaranteed that someone will use it as is without checking their own server configuration. And inexperienced webmasters were definitely part of the target group, since I wanted to make is as accessible as possible, including for those users on shared hosting webspace without access to the Apache configuration files.
- londons_explore 8y ago
  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.
blueimp 8y ago
Thanks for your comment. I do think that I share at least part of the blame. Enabling all file types by default was not necessary and would have prevented this issue. Especially since there are so many inexperienced developers using PHP, the defaults should have been secure in every perceivable Webserver configuration.
blihp 8y ago
It wasn't exactly hidden seeing as how there was a YouTube video titled 'Exploit jQuery File Upload Vulnerability' available since 2015. I don't blame the author (given the timing of the Apache change it probably would have been easy for him to overlook[1]) and it is surprising that this took years for anyone to make him aware of the issue since the exploit wasn't exactly unknown. Apparently there's some groundbreaking work left to be done in infosec searching on combinations of various library / application names and 'exploit'... [1] I assume that like most of the rest of us he was lagging behind the latest and greatest Apache release a bit. So when he was writing/testing this, it probably wouldn't have been an issue.
- blueimp 8y ago
  Unfortunately, I never tested it with an Apache configuration that had .htaccess support disabled and so it simply did not occur to me that the default was "off". I think the bigger issue was that the PHP sample code allowed all file types by default - this would not only affect Apache, but any Webserver that had broad rules to execute PHP scripts found in a directory. Originally I didn't see this as an issue as I trusted developers to securely configure their server to make sure no uploaded files would be executed, which is why the .htaccess security settings were only added later in this commit: https://github.com/blueimp/jQuery-File-Upload/commit/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1 https://github.com/blueimp/jQuery-File-Upload/commit/13931c7... But neither was the documentation informing developers clearly enough about the security implications, nor should I have relied on people actually reading security notices.
  - blihp 8y ago
    Fair enough... but I still don't blame you ;-)
    - blueimp 8y ago
      Hehe, thanks! :)
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]
lawnchair_larry 8y ago
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.
- LandR 8y ago
  Exactly this. For most developers there doesn't seem to be a differentiation between example code on a blog post and actual producation code.
vbezhenar 8y ago
Understanding what the code does is not how people generally write software. They slap components together, copy&paste examples and randomly move code lines around until it seems to work good enough. So your examples better be correct :)

by willeh 8y ago

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

blueimp 8y ago
I agree, the sample code should have been secure by default (with all web server configurations) because it's guaranteed that someone will use it as is without checking their own server configuration. And inexperienced webmasters were definitely part of the target group, since I wanted to make is as accessible as possible, including for those users on shared hosting webspace without access to the Apache configuration files.
londons_explore 8y ago
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.

blueimp 8y ago

Thanks for your comment. I do think that I share at least part of the blame. Enabling all file types by default was not necessary and would have prevented this issue. Especially since there are so many inexperienced developers using PHP, the defaults should have been secure in every perceivable Webserver configuration.

blihp 8y ago

It wasn't exactly hidden seeing as how there was a YouTube video titled 'Exploit jQuery File Upload Vulnerability' available since 2015. I don't blame the author (given the timing of the Apache change it probably would have been easy for him to overlook[1]) and it is surprising that this took years for anyone to make him aware of the issue since the exploit wasn't exactly unknown. Apparently there's some groundbreaking work left to be done in infosec searching on combinations of various library / application names and 'exploit'... [1] I assume that like most of the rest of us he was lagging behind the latest and greatest Apache release a bit. So when he was writing/testing this, it probably wouldn't have been an issue.

blueimp 8y ago
Unfortunately, I never tested it with an Apache configuration that had .htaccess support disabled and so it simply did not occur to me that the default was "off". I think the bigger issue was that the PHP sample code allowed all file types by default - this would not only affect Apache, but any Webserver that had broad rules to execute PHP scripts found in a directory. Originally I didn't see this as an issue as I trusted developers to securely configure their server to make sure no uploaded files would be executed, which is why the .htaccess security settings were only added later in this commit: https://github.com/blueimp/jQuery-File-Upload/commit/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1 https://github.com/blueimp/jQuery-File-Upload/commit/13931c7... But neither was the documentation informing developers clearly enough about the security implications, nor should I have relied on people actually reading security notices.
- blihp 8y ago
  Fair enough... but I still don't blame you ;-)
  - blueimp 8y ago
    Hehe, thanks! :)
deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

lawnchair_larry 8y ago

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.

LandR 8y ago
Exactly this. For most developers there doesn't seem to be a differentiation between example code on a blog post and actual producation code.

vbezhenar 8y ago

Understanding what the code does is not how people generally write software. They slap components together, copy&paste examples and randomly move code lines around until it seems to work good enough. So your examples better be correct :)