Hacker News new | past | comments | ask | show | jobs | submit login

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". :-)




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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: