
Dangers of remote Javascript (perl.com becomes a porn site) - toffer
http://radar.oreilly.com/archives/2008/01/dangers_of_remo.html
======
icky
Maybe a workaround:

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.

~~~
tlrobinson
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.

~~~
icky
> 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.

See my addendum: <http://news.ycombinator.com/item?id=101149>

