Can someone share some information on the reasoning behind httpd's default handling of htaccess files? How does ignoring a security feature that many relied on improve security?
Zero-day in jQuery plugin sample code exploited for at least three years
11–20 of 71 posts
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#12Author 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…
Don't beat yourself up. Your response shown here is insightful and reasonable. Well done!
Thanks a lot!
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#13Can someone share some information on the reasoning behind httpd's default handling of htaccess files? How does ignoring a security feature that many relied on improve security?
They disabled per-folder .httaccess files for performance reasons. Also for security, as it allowed server owners to control the entire server via global configs and prevent badly coded CMSs and plugins from opening security holes and bypassing stronger server-wide rules.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#14OK. I'll be that guy. Is there nobody who is going to talk about Larry Cashdollar, the person who discovered this vulnerability and first reported it?
I'm honestly not sure how I'd be more impressed; if you told me this man actually uses this as his real name in his daily life, or by finding out that this is actually his birth name.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#15Can someone share some information on the reasoning behind httpd's default handling of htaccess files? How does ignoring a security feature that many relied on improve security?
I suspect it's so that a user can't accidentally make security worse by fiddling with security settings that they don't understand. That said, I might've considered turning any page that had the disabled .htaccess settings into a 500 response instead of just keeping on like everything is working fine.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#16Author 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…
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 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/activ...
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#17Author 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…
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…
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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#18Author 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…
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…
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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#19OK. I'll be that guy. Is there nobody who is going to talk about Larry Cashdollar, the person who discovered this vulnerability and first reported it? I'm honestly not sure how I'd be more impressed; if you told me this man actually uses this as his real name in his daily life, or by finding out that this is actually his birth name.
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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#20Earlier 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…
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.