Hi malware fighters,
As we move to a Web 2.0 widget web, where the goodies on your site may not necessarily come from your site, it's worth sparing a thought for security. Imagine the following real-life scenario you just got bit on Perl.com, which redirected to a porn site courtesy to a piece of remotely-included JavaScript. One of your advertisers was using an ads system that required your pages to load JavaScript from their site. It only takes three things to turn Perl.com into porn.com: (1) the advertiser's domain lapsed, (2) the porn company bought it, (3) they replaced the JavaScript that you were loading with a small obfuscated chunk that redirected to the porn site (note that nothing on or about Perl.com changed). Your first concern will be that you'd been hacked and "run this remote JavaScript" inserted from your servers without your knowledge, but that hasn't happened—your change records and RT logs show you've had that JavaScript and advertiser since May 2008.
You will realize now that in many ways you were lucky, and the users that visit your site using NoScript—namely once an attacker can run JavaScript on your browser, very bad things may happen and will happen. So here are the questions we're asking ourselves, questions that all of you who run sites that take a lot of advertising or load a lot of widgets would do well to consider: do you know all the JavaScript your pages load? When do those domains expire? What other risks have you identified around remote JavaScript, and what are you doing to mitigate those risks? Decentralized content means decentralized security—it's up to us to ensure our systems are stronger than their weakest components. That is why I next to NoScript to be installed from here:
https://addons.mozilla.org/en-US/firefox/addon/722also use RequestPolicy to see where these requests come from, install from here:
https://addons.mozilla.org/en-US/firefox/addon/9727/Protect yourselves inside your browsers, folks, and enjoy,
polonus
