Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

zdnet.com

Post reply on HN
Print view View original

31–40 of 71 posts

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

#31

Post by [deleted] »

blihp wrote: post #18
willeh wrote: 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…

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 groundbreaki…

[deleted]

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

#32

Post by quickthrower2 »

blueimp wrote: 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…

"Zero-day in popular jQuery plugin" is a bit misleading for the title then. More like "Zero-day in copy pasted code in PHP if apache incorrectly configured".

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

#33

Post by TylerE »

quickthrower2 wrote: post #32
blueimp wrote: 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…

"Zero-day in popular jQuery plugin" is a bit misleading for the title then. More like "Zero-day in copy pasted code in PHP if apache incorrectly configured".

That’s not really true, given that the default Apache confit is vulnerable.

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

#34

Post by pdkl95 »

blueimp wrote: 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…

> 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 valid input directly.

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

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

#36

Post by Tharre »

blueimp wrote: 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!

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

#37

Post by da_chicken »

blueimp wrote: post #27
hlieberman wrote: post #19

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

> Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;)

Yet more proof that social media will bring the Internet down!

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

#39

Post by runn1ng »

galaxyLogic wrote: post #9

Isn't a JQuery Plugin something that executes on the client-side? If so then how can something on the client-side compromise the security of a server? Isn't the fault on the server-side? Or is this a PHP server-plugin which if installed on a PHP server makes them insecure? But of course anything you install on server can make it insecure. No?

There is an example PHP code in the same repo and people copy-pasted that into production.

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

Post reply on HN