Using SES to protect Klipse

We got an email on the google-caja-discuss list about using Caja:

On Mon, Jan 7, 2019 at 1:53 PM Yehonathan Sharvit <> wrote:

 My use case is [Klipse](, a javascript plugin
 that allows interactive code snippets to be embedded on a web page.

 I'd like to all blog platforms liks medium or []( to
 integrate with Klipse.

 My concern is that a malicious blog writer will write a malicious code snippet
 and use Klipse to evaluate the code snippet on the browser of blog readers.

 I am looking of a way to sanitize the evaluation function that Klipse uses to
 evaluate the code snippets.

 Could I use SES for the purpose of Klipse?

… and I thought I’d respond here.

Yes, SES is a good tool for this, or at least a good starting point. Take a look at the demo page ( , for which the source is in to get a sense of how to call it. Basically you include a script tag with the ses-shim.js file, then create a new SESRealm with SES.makeSESRootRealm(), then you evaluate code inside the realm with r.evaluate().

That will get you safe evaluation, but you probably need more than that. The important question to ask is: what kind of access (to the outside world) should this evaluated code get?

I haven’t used Klipse, but I’m assuming it’s somewhat like JSFiddle, where you’re trying to demonstrate some web technique to other people. So the snippets you’re executing are supposed to get access to the DOM. SES doesn’t give any access by default: it’s a very “pure” environment (it doesn’t even have console.log() right now, but we’re trying to fix that). The SES demo page show how you can provide safe access to specific functions from the untrusted code, and you can use that as a building block to expose more complex resources.

If you’re trying to protect the Medium/ domain from the untrusted code, then you can’t afford to expose DOM access (because it could use that to steal the login cookie/etc). However, depending upon your use case, you might exactly want to expose some kind of DOM to the code. As MarkM pointed out, this sort of virtualized DOM is the job of Domato (in the Caja repo), which is not yet built into SES (and is a ways off, I think).

hope that helps,

1 Like

Thanks @warner for the information.

In the SES github repo, it is stated:

Still under development: do not use for production systems yet, there are known security holes that need to be closed.

Are the security holes relevant to the Klipse use case?

I have gone through the public issues at , filed an additional one, and classified all of them. I labeled three as “security bugs”. One closed and two still open. The open ones are certainly fatal for SES’s security goals. You should look at them though to determine whether they are fatal for Klipse.

The public open SES issues labeled “security” are at"security+bug"+is%3Aopen

As of this writing, there are three such open security issues. We are working on them. Stay tuned.