I did get a bit out of hand with a few parts. I wanted to clarify that the idea itself is IMHO a really bad idea. To emphasize a part:
> That utility is trivially broken in multiple ways (won't announce them > on-list, but I've emailed Claude privately), and I'm pretty convinced the > idea itself is broken. That last "and" should've been a "but". I meant to place greater emphasis on the second part, not the first. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Wed, Jun 20, 2018 at 9:12 PM, doodad-js Admin <[email protected]> wrote: > I don't want to propose you my library, I want to propose you the idea. > > -----Original Message----- > From: [email protected] <[email protected]> On Behalf Of Isiah Meadows > Sent: Wednesday, June 20, 2018 7:57 PM > To: Mike Samuel <[email protected]> > Cc: doodad-js Admin <[email protected]>; es-discuss <[email protected]> > Subject: Re: FW: Proposal: safeEval > > Just a quick read, but that's a *terrible* set of ACLs, and I strongly > dislike the idea in general. That utility is trivially broken in multiple > ways (won't announce them on-list, but I've emailed Claude privately), and > I'm pretty convinced the idea itself is broken. > Limiting syntax is incredibly ineffective for anything security-related, > because there are an infinite number of ways to express something in JS, but > only a finite number of ways you can realistically limit it without breaking > it for normal users or just disabling scripting altogether. It also doesn't > stop them from accessing various globals to screw with you. > > To give a concrete example of why syntactic analysis is a bad idea for > security, let's consider eBay's encounter with JSFuck [1] [2]. Because that > literally uses only six seemingly benign characters, `[`, `]`, `!`, `+`, `(`, > and `)`, you can only protect against it by disallowing calls, which make > general use nearly impossible. It was difficult enough that eBay initially > gave up [2], until it resulted in rampant, virtually untraceable fraud in the > wild [3]. > > Now, if you disallow parentheses, you also have to ban assignment if any of > your scripts has an ID [4], because attackers can use that to their advantage > to accomplish the same objective. Claude has an option for that in his > library, but it's not especially obvious you'd need it to prevent arbitrary > code execution. > > Frozen realms together with closures provide privilege separation through > offering capabilities, which addresses who can read and/or write what. > Capabilities are better than ACLs when it comes to security, because if you > limit what they can try, they can't do what they can't try. They can't read > what they can't even try to access. > > If you want real security, focus on what people can try, not what they can > do. And this is why I say this entire proposal is complete and utter crap. > > [1]: https://github.com/aemkei/jsfuck > [2]: > https://arstechnica.com/information-technology/2016/02/ebay-has-no-plans-to-fix-severe-bug-that-allows-malware-distribution/ > [3]: > https://news.softpedia.com/news/jsf-ebay-xss-bug-exploited-in-the-wild-despite-the-company-s-fix-500651.shtml > [4]: http://syllab.fr/projets/experiments/sixcharsjs/5chars.html > > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > > > On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel <[email protected]> wrote: >> >> >> On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin <[email protected]> wrote: >>> >>> >>> >>> I was not aware of that proposal or didn’t pay attention.I think >>> “safeEval” provides ACLs, while your proposal don’t. >> >> >> Neither the realms proposal nor the frozen realms proposal include ACLs. >> >> Where are the ACLs in safeeval? >> I see some privileges via options at L72-75: >> const preventAssignment = types.get(options, 'preventAssignment', >> true), allowFunctions = types.get(options, 'allowFunctions', false), >> // EXPERIMENTAL allowNew = types.get(options, 'allowNew', false), // >> EXPERIMENTAL allowRegExp = types.get(options, 'allowRegExp', false); >> // EXPERIMENTAL but, as I understand the term, ACLs are usually the >> set of privileges available to a principal, the rows in an access >> control matrix. >> How are you defining "principal?" >> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
