For a short while recently, if you visited Perl.com, you were redirected to a porn site by malicious JavaScript. How did the JavaScript get there? Advertising. You can read a write-up of the incident at Oreilly.com.

In short, the site at Perl.com included JavaScript on the page that was hosted by one of their advertisers on a remote system. The advertiser allowed their domain to lapse and a pornographer bought it and changed the JavaScript. This is exactly the problem that I pointed out in my talk at the 2007 OWASP conference. If you’re allowing an advertiser, a site tracking service, or anyone else to run third-party JavaScript on any of your pages, you might as well send them all of your users’ data now because they can certainly steal it if they wanted to.

Many people choose not to worry about this problem because it seems unlikely to hurt them. This attacker took a lot of time and effort to do exactly that, including examining what third party JavaScript was running on the site, monitoring site expirations to take control of the advertiser’s domain, and creating his own version of the JavaScript files to do what he wanted.

You may trust your advertising partner not to maliciously attack you, but it’s important to keep in mind that the security of your users’ data is now dependent on the security of their server/domain/data as well. You take a lot of care to protect yourself. How can you be sure that they’re doing the same?

Recommendations for some ways to reduce the risks associated with third party active content can be found in my presentation via the link above.