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.
