Fwd: [Caja] Understanding the difference between Google Caja and Secure ECMAScript (SES), and if SES is ready to use



Sent from my iPhone

Begin forwarded message:

From: "'Mark S. Miller' via Google Caja Discuss" <google-caja-discuss@googlegroups.com>
Date: February 2, 2015 at 1:29:23 EST
To: Jordan Last <jordan.michael.last@gmail.com>,  Google Caja Discuss <google-caja-discuss@googlegroups.com>
Subject: Fwd: [Caja] Understanding the difference between Google Caja and Secure ECMAScript (SES), and if SES is ready to use
Reply-To: google-caja-discuss@googlegroups.com

On Fri, Jan 30, 2015 at 5:37 PM, Jordan Last <jordan.michael.last@gmail.com> wrote:
I've been scouring the internet on various occasions for quite a while now trying to figure all of this stuff out. I'm creating a web app where I have users submit JavaScript that they have written to a database, and that JavaScript is then served up and run on the browsers of other users. Obviously the user-submitted JavaScript has the potential to be dangerous. To secure it I run it through Caja, which I know does a lot of fancy stuff including potentially rewriting the code. It is a lot of overhead that I wish could be simpler, but Caja is the best that I've been able to find for me to easily secure my code. I've also heard of SES, and I'm confused. There seems to be no source that explains this well.

Hi Jordan, glad to hear that Caja and SES and useful to you. To give a clearer answer, I'm going to introduce some further terminology and distinctions.

Caja is the package securing both the browser DOM API (together with html and css) as well as JavaScript. The portion dealing with JavaScript has gone through two recent major versions:
  * ES5/3 is a server-side translator from approximately the SES subset of 
     ES5 (EcmaScript 5) to ES3 that was necessary for old browsers.
  * SES is a pure client-side securing of JavaScript that be used on ES5 
     compatible browsers, which now includes all browsers in use today
     except for IE9 (if you care about that).
The portion dealing with the DOM API (together with html and css) is Domado. Domado has been carefully refactored to work with both ES5/3 and SES.

So "old" Caja is ES5/3 + Domado.
"new" Caja is SES + Domado.

If you are interested in running JavaScript in a confined manner, but do not need to give it access to the DOM API or other APIs specific to the browser, then you don't need Domado.

The page at <https://code.google.com/p/google-caja/wiki/SES> documents the differences between SES and ES5.

 
From what I've been able to gather, SES is what is produced after running initSES.js on some JavaScript code?

Yes.


 
Apparently the initSES.js process is much simpler than the Cajoling process, because ES5 strict mode code is much easier to secure.

Yes.

 
So, is there an official version of initSES.js that I can run on ES5 Strict Mode code that will make it completely secure?

After building Caja, you will find an initSES.js in ant-lib/com/google/caja/ses/initSES.js . For reference, I attach the one I just built, but you should endeavor to rebuild it yourself so you can stay up to date.

 
If not completely secure, how secure would it be?

At <https://code.google.com/p/google-caja/wiki/SecurityAdvisories> are all the security advisories for vulnerabilities that we have found and fixed, going back to 2009. In addition, <https://code.google.com/p/google-caja/issues/list?q=label:Security> are all the public open issues in our issue tracker tagged "Security". Of course, we cannot comment on possible undisclosed vulnerabilities, but these are representative of the issues we've had. SES accounts for a minority of these.

The paper at <http://research.google.com/pubs/pub37199.html> formally analyses the security of a subset of SES it calls SES-light.
<https://github.com/brownplt/LambdaS5/tree/master/tests/ses> ran initSES on a formal model of ES5 called LambdaS5, on which they verified that the resulting state had the security properties we claim.

During the entire history of the project, no vulnerability in Caja has ever led to any known actual compromise of any site it has protected.

 
Is anyone using SES code out in the wild? Some clarification would be nice.

Not much. ES7 will introduce a Realm and Loader API, providing more direct support for object-capability security within the JavaScript language. We expect that the direct support and increase in convenience will lead to better adoption.


If the above was confusing, then to put things more simply and to summarize: 

I would like to know if I can run user-submitted ES5 Strict Mode code through initSES.js and produce SES code, without the use of Caja.

Yes, absolutely!

 

Any clarification will be greatly appreciated, thanks!

You are very welcome. Please let us know more about what you're up to if you can. Thanks!
 

--
    Cheers,
    --MarkM

--

---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-caja-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ken is an Independent Consultant in South Florida for secure cloud-based software and mobile access software. Graduated in the UK, developed the first Capability-Based Computers (PP-250), became a Charted Engineer, and awarded a Fellowship of the IEE (London). Partnered on a dozen patents developing Object Engineering fundamentals while working in UK, USA, Germany, and Belgium. Invitation speaker at conferences on Operating Systems and Communications.

Comments

Post a Comment