Scribblings

Sunday, October 14, 2007

Making JavaScript Safe with Google Caja

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.



Powered by ScribeFire.

0 Comments:

Post a Comment

<< Home