Okay, so new theory: I'll run initSES.js on my client page. Now that page is a secure environment. I'll either hit my endpoint or have the user-submitted JavaScript on the client somehow already.
The code that I write and is already present before running initSES.js interacts with the DOM based on the result of the user-submitted JavaScript, but since the user-submitted code doesn't interact with the DOM, do I need to use Caja? If not, I can just eval my the user-submitted code, and then my code can use the result to update the DOM. If I do still need to use Caja, I'll just skip running initSES.js, and to get rid of any endpoint problems I'll just pass in the user-submitted JavaScript as a string to Caja. Is that sounding better? On Wednesday, February 4, 2015 at 12:17:02 PM UTC-7, Kevin Reid wrote: > > On Wed, Feb 4, 2015 at 11:03 AM, Jordan Last <[email protected] > <javascript:>> wrote: > >> 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. >> > > The simplest solution to this problem: Instead of providing an endpoint > that delivers the JS directly, transfer it to the client via whatever means > you like (trivially: as a quoted JSON string), then pass that string to > Caja instead of a URL for Caja to fetch. > > That said, there isn't a direct risk here (other than the general one of > user-generated content delivered over HTTP to possibly content-sniffing > browsers): JavaScript runs with the 'origin' of the the HTML, not the JS, > so you would be directly vulnerable only if one of your HTML pages did a > <script src="user-problem.js">, which would be just wrong. > > 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. >> > > This doesn't actually help. SES does very little rewriting of the code, > and that little is only for compatibility, not security; the security > mechanism is the special environment SES sets up to evaluate the code in. > You're welcome to run SES on the server, but that produces a secure > environment on the server, not the client. > > -- --- 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.
