Exfiltration of user data? iframes can't do confinement. On Wed, Feb 4, 2015 at 11:48 AM, Mike Stay <[email protected]> wrote:
> What's wrong with merely running user-submitted code in an iframe? > That is, what are you trying to prevent by using Caja? > > People uploading malware? Phishing? Annoying pop-ups? > > On Wed, Feb 4, 2015 at 11:03 AM, Jordan Last > <[email protected]> wrote: > > 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. > > > > -- > Mike Stay - [email protected] > http://www.cs.auckland.ac.nz/~mike > http://reperiendi.wordpress.com > > -- > > --- > 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. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
