Comments on: Dangers of Remote Scripting

By: Adnan Siddiqi

Adnan Siddiqi — Tue, 22 Jan 2008 05:54:22 +0000

My Two Cents:
tinyurl.com/3yvxks

By: alexeiwhite

alexeiwhite — Mon, 21 Jan 2008 22:11:57 +0000

That was actually pretty clever for the porn site to do that. Touche, porno, touche.

By: crock

crock — Mon, 21 Jan 2008 03:54:31 +0000

Safe JavaScript subsets are a good option. ADsafe.org and Caja are two examples. They can work, but it is difficult to have confidence in them. It seems almost certain that new holes will be discovered which will render them useless. So in my view, safe subsets are at best a short term solution. I say that as the developer of ADsafe. I know the guys doing Caja. They are really smart, and I think Caja is good stuff. But I think they would agree with me about the vulnerability of the platform.

So we should proceed on the next level, adding communicating vats and modules. This will at least give us cooperation and better containment, but we will still be subject to XSS attacks.

XSS is a direct consequence of the design of JavaScript. JavaScript is an insecure language that invites XSS attacks. The current ES4 proposal preserves the weakness in favor of compatibility, so it is not a solution.

Ultimately we need to replace JavaScript with a secure language. That is the only way to protect our sites and our users from XSS. It will take a while to get such a thing designed, implemented, tested, standardized, and deployed, so we should proceed on that as well.

By: Mikael Bergkvist

Mikael Bergkvist — Sun, 20 Jan 2008 22:24:21 +0000

If there was a service that one could route the js through, that ’stripped out’ dangerous code before delivering it to the page requesting it?

By: Schill

Schill — Sun, 20 Jan 2008 16:48:46 +0000

Perhaps domain-aware JS would help, whereby script called from a remote domain would not have permission to set window.location and so on. “Then again”, this may not really work as any CDNs serving JS would then have issues (Akamai and so forth), despite being used for legitimate purposes. There is a lot of implicit trust in the ad model, this is an interesting (and unfortunate) example of that breaking.

By: shokk

shokk — Sun, 20 Jan 2008 15:30:28 +0000

Secret handshake using public and private keys would take no more effort than HTTPS. It’s where everything is headed.HTTPS itself shouldn’t be considered secure since many just hit OK/Continue when the dialog pops up saying there is something wrong with the cert.

By: Joseph Annino

Joseph Annino — Sun, 20 Jan 2008 15:01:57 +0000

This does raise an interesting problem that is hard to solve. Partnerships that involve running remote javascript are an important part of a lot of web sites. Its a powerful technology, allowing richer ads, content syndication, and outsourcing of page components, so business logic in javascript isn’t going to go away. It does increase your attack surface because a compromise of any of your partners can effect your site, as it did here.

You can’t really do any sort of validation in javascript, because the logic to do so would be out in the open and easily faked. I think a hybrid approach might be the best solution. Have you server do a “secret handshake” with the partner every so often, and if it fails then don’t display the script tag for their service. The handshake could go as far a cryptographic signing system that requires active support on the partner’s server, or it could be a passive system that checks for the existence of certain hidden urls and that the whois information hasn’t changed.

Any other ideas?

By: polterguy

polterguy — Sun, 20 Jan 2008 13:09:52 +0000

This is a general problem about having Business Logic in JavaScript which I have written about several times… ;)
We have a model where no BL is written in JavaScript but rather on the server which removes a whole slew of problems, this one too in fact…
Another thing it removes is the whole “Ajax is insecure” thing since everything executes on the server and as long as your server is secure then your Ajax Solution is secure since everything you do you do on the server.