As we move to a widget web, where the goodies on your site may not necessarily come from your site, it’s worth sparing a thought for security. We at O’Reilly just got bit on perl.com, which redirected to a porn site courtesy a piece of remotely-included Javascript. One of our advertisers was using an ads system that required our pages to load Javascript from their site. It only took 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 we were loading with a small chunk that redirected to the porn site (note that nothing on or about perl.com changed). Our first concern was that we’d been hacked and “run this remote Javascript” inserted from our servers without our knowledge, but that hadn’t happened—our change records and RT logs show we’ve had that Javascript and advertiser since May 2006.
After seeing Rasmus‘s excellent talk on web security at OSDC, I realize that in many ways we were lucky—once an attacker can run Javascript on your browser, very bad things can 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.