Friday, October 12th, 2007

Making JavaScript Safe with Google Caja

Category: Google, Security

Douglas Crockford continues to bang the drum for securing JavaScript in his latest post:

It is possible to make secure programming languages. Most language designers do not consider that possibility. JavaScript’s biggest weakness is that it is not secure. That puts JavaScript in very good company, but it puts web developers in an untenable position because they cannot build secure applications in an insecure language. JavaScript is currently going through a redesign that is again failing to consider the security of the language. The new language will be bigger and more complex, which will make it even harder to reason about its security. I hope that that redesign will be abandoned.

A more fruitful approach is to remove insecurity from the language. JavaScript is most easily improved by removing defective features. I am aware of two approaches that allow us to build secure applications by subsetting the insecure language.

The first approach is to use a verifier. That is how ADsafe works. A verifier statically analyzes a program, and certifies that the program does not use any of the unsafe features of the language. This does not guarantee that the program is safe, but it makes it possible to make programs that are safe. Any program can compromise its own security. The improvement here is that a program’s security is not compromised by the language it is written in.

The second approach is to use a transformer. A transformer verifies, but it also modifies the program, adding indirection and runtime checks. The advantage of transformers is that they allow the use of a larger subset of the language. For example, ADsafe does not allow the use of the this parameter. A transformer can allow this because it can inject code around it and its uses to ensure that it is never used unsafely. The benefit is that it is more likely that existing programs could run in a safe mode with little or no modification. I think that is a dubious benefit because programs that are not designed to be safe probably are not. The downside is that the final program will be bigger and slower, and debugging on the transformed program will be more difficult.

Both approaches work. But we still need to fix the browser.

A new project, Google Caja, is trying to do source-to-source translation to secure things:

Using Caja, web apps can safely allow scripts in third party content.

The computer industry has only one significant success enabling documents to carry active content safely: scripts in web pages. Normal users regularly browse untrusted sites with Javascript turned on. Modulo browser bugs and phishing, they mostly remain safe. But even though web apps build on this success, they fail to provide its power. Web apps generally remove scripts from third party content, reducing content to passive data. Examples include webmail, groups, blogs, chat, docs and spreadsheets, wikis, and more.

Were scripts in an object-capability language, web apps could provide active content safely, simply, and flexibly. Surprisingly, this is possible within existing web standards. Caja represents our discovery that a subset of Javascript is an object-capability language.

FBJS is also trying to do some of this too. Got some time on Friday to look around some code? Take a look at some Caja.

Posted by Dion Almaer at 10:58 am
12 Comments

+++--
3.9 rating from 16 votes

12 Comments »

Comments feed TrackBack URI

is it a official google project?

Comment by Uriel Katz — October 12, 2007

Looks official (// Copyright (C) 2007 Google Inc.), research focused

Doing this in javascript doesn’t make any practical sense to me, but their research is amazing:
http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf

We need to fix the browser that for sure. Would be nice to see collaboration, there’s a new effort at OpenAjax to propose changes to browser vendors:

http://www.openajax.org/member/wiki/Runtime

Comment by Jonathan Bond-Caron — October 12, 2007

…I love Dion’s ‘teaser’ quote… it’s the entire Crockford article copied and pasted ;)
Great info though, as always! Thanks, guys.

Comment by Mark Holton — October 12, 2007

This would make it much easier for mashups to run untrusted scripts, but I think this really needs to happen in the browser.

Of course, due to all the browser inconsistencies of the 90’s, I can understand why people are afraid of that. But there is no substitute for correctness.

Hopefully, the big boys of the internet (Google / Yahoo) are putting pressure on the browser vendors to make these changes. But, what’s the motivation (ie $$) to improve browsers anymore?

Comment by Justin Meyer — October 12, 2007

I agree, ripping off the entire content of someone’s article isn’t satisfied by a courtesy link to it. Bad move

Comment by Chess — October 12, 2007

Seems to me that everyday users need to be able to clearly see what information is being sent from their browser and to what destination–along with a control for permitting it and denying it. This way individuals remain responsible for their own information, privacy, etc and are empowered to control it (along with firewall, adblockers, etc). Personally I see this as having way more longevity, reliability and simplicity than fixing/changing the languages/technologies across all the browsers, getting everyone to use the new products, educating developers, etc, etc.

Comment by Jim — October 12, 2007

Post advertisement at http://fivq.com/ . There you can offer your services, find gigs (short term jobs) or long term jobs. It is good place who would like to work remotely. Also there you can promote your website, your services. Between its absolutely free to post and no registration needed.

Comment by Vytas — October 13, 2007

Javascript is a strong way to make a site look more “cool” or easy to use but all the people i know think twice before using javascript to manage data, they prefer many other languages but all of them would be happy to manage all from one language, otherwise using one for a feauture and one for another… why the “bosses” don’t work on this?

Comment by Christian Pulcinelli — October 13, 2007

I think it’s really sad that such a great developer as Douglas is determined on “fixing something that’s NOT broken”… :(
BTW security in Ajax is a NON-issue if you’re using a server-centric Ajax Framework like e.g. Gaia Ajax Widgets…
If I were to “break” the language and don’t think about backwards compatibility I’d say it’s a 100 times more important to bring in namespaces and avoid the “garbage bin” of “window.x” – global “namespace”…

Comment by Thomas Hansen — October 13, 2007

This is all great, but… what IS Caja exactly?

Comment by misuba — October 15, 2007

is google behind this?

Comment by Aphrodisiac — July 31, 2008

@Aphrodisiac yes google is behind this. There was a great presentation on this at The Ajax Experience in Boston two weeks ago.

@misuba not to speak for the project, Caja basically reads in a third party script, and rewrites it in a safe way. it allows you to compose application from untrusted third parties and even enables communication between those scripts.

@Jim I think you have to remember that users of this site don’t accurately represent everyday users. I know this may sound crazy, but most people barely know what a browser is, never mind putting thought into which one is better, faster, safer. Most people just know that the Big Blue E that “came with” their computer is the internet.

Comment by maddesa — September 30, 2009

Leave a comment

You must be logged in to post a comment.