Page 1 of 1

jQuery.com compromised to serve malware

Posted: Fri Sep 26, 2014 4:58 pm
by therube
jQuery.com compromised to serve malware via drive-by download

http://blog.jquery.com/

http://jquery.com/

"We took the site down as soon as we realized there was a compromise and cleaned the infected files."

Now just what does all this mean?

Is this one of those "you're not supposed to do that sites", where everyone links to its code, & often you may need to Allow it in order for particular functions used on a particular page to work?

And if they "took the site down", then what? Those sites that rely on it, break? Or do the sites just use the "compiled" code & are only loading it locally?

Site was hit, but not the library


Do you "trust" jquery, or similar.

Re: jQuery.com compromised to serve malware

Posted: Tue Sep 30, 2014 4:03 am
by Thrawn
Is anyone successfully running JQuery via a file: surrogate?

Re: jQuery.com compromised to serve malware

Posted: Fri Oct 10, 2014 7:29 pm
by barbaz
To note, I posted the following when a user asked about replacing googleapis jQuery and seemed concerned about the compromise of the official site:
You could download jquery from some other mirror site, such as ajax.aspnetcdn.com (Microsoft) (click the link I posted, don't try to go directly to the domain because that will just give you a not found page)

Re: jQuery.com compromised to serve malware

Posted: Fri Oct 10, 2014 11:07 pm
by IanR
These site attacks are becoming all too commonplace, and the usual vector is SQL code injection. Seems it's uncertain if this was the case here, but extremely likely as they were using a database-backed CMS.

Basically, the need is for an SQL replacement which understands the concept of variables, and thus does not have to accept its input as mixed data and instructions on the same line. Until that is implemented, the code injection exploits will continue.

Re: jQuery.com compromised to serve malware

Posted: Sun Oct 12, 2014 10:33 pm
by Thrawn
IanR wrote:Basically, the need is for an SQL replacement which understands the concept of variables, and thus does not have to accept its input as mixed data and instructions on the same line. Until that is implemented, the code injection exploits will continue.

Yeah. After that's done, we just need a similar intelligent replacement for HTML, and the web is all fixed :)