Injection of malicious code into jQuery is increasing(blog.spiderlabs.com)
blog.spiderlabs.com
Injection of malicious code into jQuery is increasing
http://blog.spiderlabs.com/2014/01/beware-bats-hide-in-your-jquery-.html
8 comments
This piece doesn't seem to make any distinction between jQuery core, and jQuery plugins. If the lesson is "don't just stick random 3rd party scripts onto your site" then thats obviously good advice. If it's "don't trust jQuery, it might be dangerous", then I think they're just scaremongering.
What seems to be happening is that someone's server gets compromised, and the attacker uploads malicious JavaScript to attack the site's visitors. Of course, a competent admin will reverse these changes as soon as they are detected. So, attackers have started modifying the copy of jQuery that's already deployed on that server to insert malicious code, as the developer is unlikely to notice or overwrite changes to that file.
So, the message is "don't trust anything on your server if it might have been compromised". :-)
So, the message is "don't trust anything on your server if it might have been compromised". :-)
And this would be a reason to use a trusted CDN location for serving your jQuery library.
Actually, these shared "JavaScript CDNs" actually slow down your site.
http://zoompf.com/blog/2010/01/should-you-use-javascript-lib... http://statichtml.com/2011/google-ajax-libraries-caching.htm...
tl;dr: the URLs are too fragmented to get cache hits for commonly used shared libraries, so you end up having to do a DNS lookup and download them over a cold TCP/HTTP connection. This is slower than simply serving the 20-30KB of data directly from you own site.
Update even more recent stats from 2013. The Html5 boiler plate project decided against shared JavaScript CDNs: https://github.com/h5bp/html5-boilerplate/pull/1327
http://zoompf.com/blog/2010/01/should-you-use-javascript-lib... http://statichtml.com/2011/google-ajax-libraries-caching.htm...
tl;dr: the URLs are too fragmented to get cache hits for commonly used shared libraries, so you end up having to do a DNS lookup and download them over a cold TCP/HTTP connection. This is slower than simply serving the 20-30KB of data directly from you own site.
Update even more recent stats from 2013. The Html5 boiler plate project decided against shared JavaScript CDNs: https://github.com/h5bp/html5-boilerplate/pull/1327
The Html5 boiler plate project decided against shared JavaScript CDNs: https://github.com/h5bp/html5-boilerplate/pull/1327
No. If you jump to the end of the long discussion, the last comment says:
I'm sure there will be a similar discussion in the near future (especially as things such as SPDY / HTTP 2.0 get more traction), but for the time being, we'll stick with the CDN.
No. If you jump to the end of the long discussion, the last comment says:
I'm sure there will be a similar discussion in the near future (especially as things such as SPDY / HTTP 2.0 get more traction), but for the time being, we'll stick with the CDN.
Or a reason to use something like tripwire.
I'm amazed by the number of admins that don't know about this tool.
not if ISP, nsa, etc are involved.
I don't think the author has a clue of what they are writing about...
"In this case, speed and efficiency have higher priority than human readability, therefore jQuery includes only essential features to keep the code tight and focused by using minimal variable and function names, minimal use of spaces, no comments, etc."
Someone mixing library purpose with minification process.
And I bet that all those infected scripts come from one infected website. They're not out there in the wild spreading through all jQuery installations and all jQuery plugins.
"In this case, speed and efficiency have higher priority than human readability, therefore jQuery includes only essential features to keep the code tight and focused by using minimal variable and function names, minimal use of spaces, no comments, etc."
Someone mixing library purpose with minification process.
And I bet that all those infected scripts come from one infected website. They're not out there in the wild spreading through all jQuery installations and all jQuery plugins.
>>> And I bet that all those infected scripts come from one infected website.
Or one platform - Wordpress.
"Checkmarx, makers of an automated code review solution, recently looked at the top 50 plugins for WordPress examining them for vulnerabilities. Their analysis, published here, found 20% of the top 50 were vulnerable to the most common web attacks. Even more frightening, 7 out of 10 of the leading ecommerce plugins were vulnerable."
"To put this in perspective, this means that vulnerable plugins were downloaded to install in websites about 8 million times!"
http://www.networkworld.com/community/blog/7-10-leading-word...
Or one platform - Wordpress.
"Checkmarx, makers of an automated code review solution, recently looked at the top 50 plugins for WordPress examining them for vulnerabilities. Their analysis, published here, found 20% of the top 50 were vulnerable to the most common web attacks. Even more frightening, 7 out of 10 of the leading ecommerce plugins were vulnerable."
"To put this in perspective, this means that vulnerable plugins were downloaded to install in websites about 8 million times!"
http://www.networkworld.com/community/blog/7-10-leading-word...
Actually, they are spreading in the wild, sort of.
There is a parallel universe, where people called "webmasters" upload websites to a hosting account with ftp. They use outdated php cms systems, their home directory is writable by the user/grourp that runs the webserver. They dont use version control and cant tell when a js file is injected with malicious code. They all get injected with js malware every day. There is malware that targets cmses specifically and injects code in the cms libraries or config files directly.
There is a parallel universe, where people called "webmasters" upload websites to a hosting account with ftp. They use outdated php cms systems, their home directory is writable by the user/grourp that runs the webserver. They dont use version control and cant tell when a js file is injected with malicious code. They all get injected with js malware every day. There is malware that targets cmses specifically and injects code in the cms libraries or config files directly.
I am confused. Is this saying that library authors are accepting pull request with malicious code, or that if you compromise a site, a good place to stick your malicious code is into a jQuery plugin library?
I do appreciate that this article points out that malicious attacks may come from compromised jQuery files, but this is poorly written.
Are there any other more credible sources of reporting on this? Not only is the article very vague and alarmist but it also ends with a call to action to buy security audit software from the author's company, which makes me pretty skeptical...
ehh??