FW: Proposal: safeEval

[Isiah Meadows]

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
me at isiahmeadows.com
www.isiahmeadows.com


On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>
>
> On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin <doodadjs at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>