Thank you so much for the reply! It is helpful and appreciated. I'll give you a little background on the project:
We are creating a website/webapp that allows users to create practice problems for different educational subjects (math, science, physics, history, etc.). They type up the presentation of their problem and then code the solution in JavaScript. The reason the user codes the solution is because these problems generate new numbers/words and answers each time they are accessed. The user can submit their problem, and it then becomes available to other users (there will be some checks and balances in place as well). That's the basic idea. The security issues arise with serving up user-submitted practice problems to other users. Right now I have an endpoint that Caja on the client's machine hits to grab the JavaScript for a problem. It then does its stuff and securely runs the JavaScript, handing all of the information I need safely to a tamed function where I can then present what I need to the user. It works just fine. But, that endpoint is not secure. It serves up un-Cajoled JavaScript, and is not limited to being hit by Google Caja from the client's machine. What is stopping anyone else from hitting that endpoint? From what I've been able to gather, there really is no sure way to secure that endpoint. I could use tokens to restrict access to logged-in users, but I want the practice problems to be available to anyone, not just users. I suppose I could generate a temporary token with each practice problem that a user accesses, and then send it with Caja's request to the endpoint, and then have it expire after a short time. But I think that could even be intercepted by someone who can code and is determined. Maybe I'm too worried about this endpoint being open to the world, but I don't think it's a good idea to serve up insecure JavaScript. But, with what you've helped me understand about SES and initSES.js, I might have a better solution now. I hope you can steer me in the right direction if I'm off on this. A better idea would be to run initSES.js on the user-submitted JavaScript on the server (I'm using node.js). Then my endpoint can serve up SES code that is already safe and sanitized! And then my client application can just use the code as it pleases, without worry. So, that's a little bit about what I'm up to. If I'm completely off somewhere, I would love to know. Thanks for the help again! On Friday, January 30, 2015 at 6:37:41 PM UTC-7, Jordan Last 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. From what I've been > able to gather, SES is what is produced after running initSES.js on some > JavaScript code? Apparently the initSES.js process is much simpler than the > Cajoling process, because ES5 strict mode code is much easier to secure. > So, is there an official version of initSES.js that I can run on ES5 Strict > Mode code that will make it completely secure? If not completely secure, > how secure would it be? Is anyone using SES code out in the wild? Some > clarification would be nice. > > 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. > > Any clarification will be greatly appreciated, thanks! > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
