1. Ad server signs the text of the javascript code with an HMAC-style digest with a shared (private) key. Maybe the first line of the text is the hash of the rest of it. (Possibly also an advertiser-id jammed in there so the site knows which key to check).
2. Client pulls the javascript as plain text via XMLHttpRequest. (May require hacks or flash to do cross-domain on some browsers. :-( )
3. Client sends the whole thing via a POST XMLHttpRequest to the site's server. (Remember, that only the advertiser and the site can have the same key; if the client can get it, the attacking site can, too).
4. Site's server returns some OK message with the hash to the client.
5. Client javascript calls eval on the text of the javascript.
That should keep anyone from injecting malicious javascript by stealing the advertiser's domain. It does NOT protect against an attacker who has managed to get ahold of the secret key, but that's a lot trickier for them to do.
If the advertiser is okay with it, you could have it work like this:
1. Client makes HTTP GET request from the site's server.
(1a. If the page has to load before the advertisement does, the site server returns immediately and the client makes an XMLHttpRequest to the site server, then proceed to step 2.)
2. Site's server GETs the javascript-text plus digest from the advertiser, checks the digest, then sends the javascript to the client to be eval()'d.
Since the final javascript is the one that will be loading the advertisement's images, links, etc., the advertiser can still independently verify that an actual user is viewing the ad.
Interesting idea. That seems like a lot of work, not to mention the same origin policy issues. Why not just validate it server side? A simple server side script could pull the JavaScript from the advertiser, verify it, and pass it on to the client.
Or use a public key signature and verify it client-side, though that would require the encryption algorithm implemented in JavaScript.
However, why do advertisement need JavaScript in the first place? As demonstrated by this incident, you're trusting the advertisers not to do bad things on your site.
> Why not just validate it server side? A simple server side script could pull the JavaScript from the advertiser, verify it, and pass it on to the client.
1. Ad server signs the text of the javascript code with an HMAC-style digest with a shared (private) key. Maybe the first line of the text is the hash of the rest of it. (Possibly also an advertiser-id jammed in there so the site knows which key to check).
2. Client pulls the javascript as plain text via XMLHttpRequest. (May require hacks or flash to do cross-domain on some browsers. :-( )
3. Client sends the whole thing via a POST XMLHttpRequest to the site's server. (Remember, that only the advertiser and the site can have the same key; if the client can get it, the attacking site can, too).
4. Site's server returns some OK message with the hash to the client.
5. Client javascript calls eval on the text of the javascript.
That should keep anyone from injecting malicious javascript by stealing the advertiser's domain. It does NOT protect against an attacker who has managed to get ahold of the secret key, but that's a lot trickier for them to do.