Re: [Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

2018-06-20 Thread Andrea Giammarchi 
> You could even use filter(function(f){f.name==‘abc’;}).length > 0

not really, that's a long way to find what you are looking for, `some`
stops ASAP instead.

> The focus of this proposal is that the purpose of .valueOf and .toString

I think those have valid use cases and changing a method already shipped
long time ago to make use of those methods is surely not one of them.

This will never happen, you might have better luck proposing a new method
(yet I have the feeling it won't happen neither because it's too easy to do
on user land).

Regards


On Wed, Jun 20, 2018 at 8:54 PM, Mike Simon  wrote:

> True, there are many other ways to make this work. You could even use
> filter(function(f){f.name==‘abc’;}).length > 0 .
>
> The focus of this proposal is that the purpose of .valueOf and .toString
> are to allow for objects to return a default value without requiring the
> matching method to know about the contents or property names of any of
> next.
>
> Array.prototype.some, and any method mentioned above require a that a
> content aware function be passed in to facilitate the match.  This proposal
> mitigates that, and allows Array.prototype.includes to evaluate the object
> as the object design was intended.
>
> On Jun 20,  2018, at 11:33 AM, Andrea  
> wrote:
>
> It looks like you want included to use `==` for comparison, opening a
> whole new world of issues.
>
> You have `some` and your code to do that with ease, same goes for `find`
> or `findIndex`, very appropriate for this use case.
>
> ```js
> items.some(o => o == 'abc');
> ```
>
> Regards
>
> On Wed, Jun 20, 2018 at 8:27 PM, Mike Simon  wrote:
>
>> [Proposal] Array.prototype.includes should evaluate object.toString
>> and/or object.valueOf when determining a match
>>
>> The problem:
>>
>> If I have a list of objects that contain a toString() prototype that
>> returns a value from the object, Array.prototype.includes does not return
>> true if the value/string returned from the object is a match for the
>> parameter value.
>>
>> Test code:
>>
>> var thingy = function(name) {this.name=name;};
>> thingy.prototype.valueOf = function(){return this.name};
>> thingy.prototype.toString = function(){return this.name};
>> var items = [new thingy('abc'),new thingy('def')];
>> var inc = items.includes('abc');
>> alert(items[0]); // alerts abc
>> alert(inc); // returns false
>>
>> While it’s possible to create this as a list of strings using map, this
>> would seem to conserve memory, as well as reduce the complexity of the code
>> to perform this operation.
>>
>> Link: https://developer.mozilla.org/en-US/docs/Web/JavaScrip
>> t/Reference/Global_Objects/Array/includes
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

FW: Proposal: safeEval

2018-06-20 Thread doodad-js Admin 




From: Claude Petit 
Sent: Wednesday, June 20, 2018 2:23 PM
To: 'mikesam...@gmail.com' 
Cc: 'es-discuss' 
Subject: RE: Proposal: safeEval



Thanks,



How would this compare to https://github.com/tc39/proposal-frozen-realms ?



I was not aware of that proposal or didn’t pay attention.I think “safeEval” 
provides ACLs, while your proposal don’t.



I'm not sure how to run @doodad-js/safeeval in node



That’s a Doodad module, and it must be loaded by Doodad before usage. Anyway, 
that’s not important.



What does it do for inputs like



Sure, as I told you, that’s very incomplete. I’m just bringing the idea. But 
I’ll fix that issues if they are present.





Claude



From: Mike Samuel mailto:mikesam...@gmail.com> >
Sent: Wednesday, June 20, 2018 9:51 AM
To: dooda...@gmail.com 
Cc: es-discuss mailto:es-discuss@mozilla.org> >
Subject: Re: Proposal: safeEval



How would this compare to https://github.com/tc39/proposal-frozen-realms ?



I'm not sure how to run @doodad-js/safeeval in node since require doesn't

provide obvious access to safeeval, but the code seems to do AST filtering.

What does it do for inputs like



safeEval(' 0..constructor.constructor("alert(1)")() ')

safeEval(' 0[x][x]`alert(1)`() ', { x: 'constructor' })

safeEval(' 0[x][y] = null ', { x: 'prototype', y: 'toString' })







On Tue, Jun 19, 2018 at 10:29 PM doodad-js Admin mailto:dooda...@gmail.com> > wrote:

Hi,



I take a chance to valorize “eval” again by proposing “safeEval”.



function safeEval(expression, [locals], [options]) {

..

};



So that you can:



safeEval(“1 + a”, {a: 2});// returns “3”

safeEval(“1 + a()”, {a: function() {return 2}}, {allowFunctions: true});// 
also returns “3”



but:



safeEval(“1 + a()”, {a: function() { return 2}});// throws whatever you 
want because “allowFunctions” is denied



etc.



Note that local variables are specified in argument. Also note that “options” 
mainly gives/denies permissions. I’m not sure if we should be whitelisting or 
blacklisting features there though, or a mix of default enabled and disabled 
ones...



Very incomplete, but as for inspiration (and very useful to me): 
https://www.npmjs.com/package/@doodad-js/safeeval





Claude






 


Virus-free.  

 www.avg.com 

___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss



---
This email has been checked for viruses by AVG.
https://www.avg.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

2018-06-20 Thread Andrea Giammarchi 
It looks like you want included to use `==` for comparison, opening a whole
new world of issues.

You have `some` and your code to do that with ease, same goes for `find` or
`findIndex`, very appropriate for this use case.

```js
items.some(o => o == 'abc');
```

Regards

On Wed, Jun 20, 2018 at 8:27 PM, Mike Simon  wrote:

> [Proposal] Array.prototype.includes should evaluate object.toString
> and/or object.valueOf when determining a match
>
> The problem:
>
> If I have a list of objects that contain a toString() prototype that
> returns a value from the object, Array.prototype.includes does not return
> true if the value/string returned from the object is a match for the
> parameter value.
>
> Test code:
>
> var thingy = function(name) {this.name=name;};
> thingy.prototype.valueOf = function(){return this.name};
> thingy.prototype.toString = function(){return this.name};
> var items = [new thingy('abc'),new thingy('def')];
> var inc = items.includes('abc');
> alert(items[0]); // alerts abc
> alert(inc); // returns false
>
> While it’s possible to create this as a list of strings using map, this
> would seem to conserve memory, as well as reduce the complexity of the code
> to perform this operation.
>
> Link: https://developer.mozilla.org/en-US/docs/Web/
> JavaScript/Reference/Global_Objects/Array/includes
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

2018-06-20 Thread Mike Samuel 
On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin  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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

2018-06-20 Thread Mike Simon 
True, there are many other ways to make this work. You could even use 
filter(function(f){f.name==‘abc’;}).length > 0 .

The focus of this proposal is that the purpose of .valueOf and .toString are to 
allow for objects to return a default value without requiring the matching 
method to know about the contents or property names of any of next. 

Array.prototype.some, and any method mentioned above require a that a content 
aware function be passed in to facilitate the match.  This proposal mitigates 
that, and allows Array.prototype.includes to evaluate the object as the object 
design was intended. 

> On Jun 20,  2018, at 11:33 AM, Andrea   wrote:
> 
> It looks like you want included to use `==` for comparison, opening a whole 
> new world of issues.
> 
> You have `some` and your code to do that with ease, same goes for `find` or 
> `findIndex`, very appropriate for this use case.
> 
> ```js
> items.some(o => o == 'abc');
> ```
> 
> Regards
> 
>> On Wed, Jun 20, 2018 at 8:27 PM, Mike Simon  wrote:
>> [Proposal] Array.prototype.includes should evaluate object.toString and/or 
>> object.valueOf when determining a match
>> 
>> The problem:  
>> 
>> If I have a list of objects that contain a toString() prototype that returns 
>> a value from the object, Array.prototype.includes does not return true if 
>> the value/string returned from the object is a match for the parameter value.
>> 
>> Test code:
>> 
>> var thingy = function(name) {this.name=name;};
>> thingy.prototype.valueOf = function(){return this.name};
>> thingy.prototype.toString = function(){return this.name};
>> var items = [new thingy('abc'),new thingy('def')];
>> var inc = items.includes('abc');
>> alert(items[0]); // alerts abc
>> alert(inc); // returns false
>> 
>> While it’s possible to create this as a list of strings using map, this 
>> would seem to conserve memory, as well as reduce the complexity of the code 
>> to perform this operation. 
>> 
>> Link: 
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

2018-06-20 Thread Peter Jaszkowiak 
If you want to check properties or methods of an array of objects, you can
use `Array.prototype.some`.

On Wed, Jun 20, 2018, 12:27 Mike Simon  wrote:

> [Proposal] Array.prototype.includes should evaluate object.toString
> and/or object.valueOf when determining a match
>
> The problem:
>
> If I have a list of objects that contain a toString() prototype that
> returns a value from the object, Array.prototype.includes does not return
> true if the value/string returned from the object is a match for the
> parameter value.
>
> Test code:
>
> var thingy = function(name) {this.name=name;};
> thingy.prototype.valueOf = function(){return this.name};
> thingy.prototype.toString = function(){return this.name};
> var items = [new thingy('abc'),new thingy('def')];
> var inc = items.includes('abc');
> alert(items[0]); // alerts abc
> alert(inc); // returns false
>
> While it’s possible to create this as a list of strings using map, this
> would seem to conserve memory, as well as reduce the complexity of the code
> to perform this operation.
>
> Link:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Inline ES Modules

2018-06-20 Thread Andrea Giammarchi 
Darien others replied about CSP but also `script-src data: unsafe-inline`
would work as well. There is no evaluation, or at least, nothing different
from loading static content there (OK, the dynamic import could be a
different story, yet if pre-processed I don't see it as useful, but surely
one day someone will prove me wrong ^_^;; ).

About IANA vs HTML, I think both should be supported, specially because
IANA states text/javascript is deprecated and most developers serve JS via
application/javascript, or JSON as  application/json (and there is no
text/json).

WebKit / Safari handles both cases without issues, Chrome chokes on the
application/javascript but it's IMO a non sense to allow one but not the
other, so I've filed a bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=854370

Regards



On Wed, Jun 20, 2018 at 1:56 AM, Darien Valentine 
wrote:

> Andrea: That is a really interesting approach. I would point out that
> using data URIs for js means the `data:` scheme has to be a permitted
> source for script-src. This allowance has roughly the same security
> implications as permitting `unsafe-eval`. I know most people aren’t using
> CSPs yet, but personally I’d be wary of a solution that makes it harder to
> adopt a strong CSP.
>
> A super dorky/tangential aside that probably doesn’t matter at all but ...
> I notice you used application/javascript for the media type. There’s a
> contradiction between the IANA media type registry and the HTML 5 spec with
> regard to the "correct" media type to use for JS. RFC 4329 says
> application/javascript is the only value that should be used, while HTML
> says text/javascript is the only value that should be used. I believe (not
> sure though) that this is because it’s the most backwards-compatible value.
> Given that the media types registry seems to be basically dead to web
> standards (if we follow the registry we can’t serve or post a bunch of
> media types acknowledged or defined by web standards at all, including
> image/webp, application/csp-report, etc) and the code has to run in a
> browser, I’d tend to think HTML is the better spec to follow ... though I
> guess when two specs contradict each other it’s hard to make an objective
> case for one being more authoritative. (I’d be curious if there’s a
> specific reason you know of to prefer to RFC definition though. When
> standards don’t align it breaks my tiny heart.)
>
> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> sorry, I meant:
>>
>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking);
>>
>>
>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>>
>>> I think these are all nice to have features, but I also think we have
 all the primitives we need to make it happen via pre-processing.

>
>>> I meant even synchronously, with a pre-processor that replace the
>>> imported module with
>>>
>>> 'data:text/javascript,' + JSON.stringify(moduleContentAfterTreeShaking);
>>>
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

2018-06-20 Thread Mike Samuel 
How can we discuss your idea separately from the library?

You talk about options and ACLs but the only hint as to what those might
mean is the library.

How would the idea work if not by tree filtering?  AdSAFE did that but
writing AdSAFE was very different from writing vanilla JS.


On Wed, Jun 20, 2018, 9:12 PM doodad-js Admin  wrote:

> I don't want to propose you my library, I want to propose you the idea.
>
> -Original Message-
> From: impinb...@gmail.com  On Behalf Of Isiah Meadows
> Sent: Wednesday, June 20, 2018 7:57 PM
> To: Mike Samuel 
> Cc: doodad-js Admin ; es-discuss <
> es-discuss@mozilla.org>
> 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
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel  wrote:
> >
> >
> > On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin 
> 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@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Proposal: safeEval

2018-06-20 Thread Isiah Meadows 
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
m...@isiahmeadows.com
www.isiahmeadows.com


On Wed, Jun 20, 2018 at 9:12 PM, doodad-js Admin  wrote:
> I don't want to propose you my library, I want to propose you the idea.
>
> -Original Message-
> From: impinb...@gmail.com  On Behalf Of Isiah Meadows
> Sent: Wednesday, June 20, 2018 7:57 PM
> To: Mike Samuel 
> Cc: doodad-js Admin ; es-discuss 
> 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
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel  wrote:
>>
>>
>> On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin  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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: FW: Proposal: safeEval

2018-06-20 Thread doodad-js Admin 
Thanks

 

How can we discuss your idea separately from the library?

 

I’m more thinking at the runtime level than at the “user land”. To be honest, I 
don’t care of “safeEval” on “user land”.

 

You talk about options and ACLs but the only hint as to what those might mean 
is the library

How would the idea work if not by tree filtering?  AdSAFE did that but writing 
AdSAFE was very different from writing vanilla JS.

 

Yeah, sorry. The purpose is to offer something like “opcode” filtering, but in 
a more expressive and user-friendly way.

 

Claude

 

 

From: Mike Samuel  
Sent: Wednesday, June 20, 2018 9:37 PM
To: doodad-js Admin 
Cc: Isiah Meadows ; es-discuss 
Subject: Re: FW: Proposal: safeEval

 

How can we discuss your idea separately from the library?

 

You talk about options and ACLs but the only hint as to what those might mean 
is the library.

 

How would the idea work if not by tree filtering?  AdSAFE did that but writing 
AdSAFE was very different from writing vanilla JS.

 

On Wed, Jun 20, 2018, 9:12 PM doodad-js Admin mailto:dooda...@gmail.com> > wrote:

I don't want to propose you my library, I want to propose you the idea.

-Original Message-
From: impinb...@gmail.com   mailto:impinb...@gmail.com> > On Behalf Of Isiah Meadows
Sent: Wednesday, June 20, 2018 7:57 PM
To: Mike Samuel mailto:mikesam...@gmail.com> >
Cc: doodad-js Admin mailto:dooda...@gmail.com> >; 
es-discuss mailto:es-discuss@mozilla.org> >
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
m...@isiahmeadows.com  
www.isiahmeadows.com  


On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel mailto:mikesam...@gmail.com> > wrote:
>
>
> On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin   > 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@mozilla.org

Re: FW: Proposal: safeEval

2018-06-20 Thread 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
m...@isiahmeadows.com
www.isiahmeadows.com


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

RE: FW: Proposal: safeEval

2018-06-20 Thread doodad-js Admin 
I don't want to propose you my library, I want to propose you the idea.

-Original Message-
From: impinb...@gmail.com  On Behalf Of Isiah Meadows
Sent: Wednesday, June 20, 2018 7:57 PM
To: Mike Samuel 
Cc: doodad-js Admin ; es-discuss 
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
m...@isiahmeadows.com
www.isiahmeadows.com


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

---
This email has been checked for viruses by AVG.
https://www.avg.com


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

2018-06-20 Thread Mike Simon 
[Proposal] Array.prototype.includes should evaluate object.toString and/or 
object.valueOf when determining a match

The problem:  

If I have a list of objects that contain a toString() prototype that returns a 
value from the object, Array.prototype.includes does not return true if the 
value/string returned from the object is a match for the parameter value.

Test code:

var thingy = function(name) {this.name=name;};
thingy.prototype.valueOf = function(){return this.name};
thingy.prototype.toString = function(){return this.name};
var items = [new thingy('abc'),new thingy('def')];
var inc = items.includes('abc');
alert(items[0]); // alerts abc
alert(inc); // returns false

While it’s possible to create this as a list of strings using map, this would 
seem to conserve memory, as well as reduce the complexity of the code to 
perform this operation. 

Link: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: safeEval

2018-06-20 Thread Mike Samuel 
How would this compare to https://github.com/tc39/proposal-frozen-realms ?

I'm not sure how to run @doodad-js/safeeval in node since require doesn't
provide obvious access to safeeval, but the code seems to do AST filtering.
What does it do for inputs like

safeEval(' 0..constructor.constructor("alert(1)")() ')
safeEval(' 0[x][x]`alert(1)`() ', { x: 'constructor' })
safeEval(' 0[x][y] = null ', { x: 'prototype', y: 'toString' })



On Tue, Jun 19, 2018 at 10:29 PM doodad-js Admin  wrote:

> Hi,
>
>
>
> I take a chance to valorize “eval” again by proposing “safeEval”.
>
>
>
> function safeEval(expression, [locals], [options]) {
>
> ..
>
> };
>
>
>
> So that you can:
>
>
>
> safeEval(“1 + a”, {a: 2});// returns “3”
>
> safeEval(“1 + a()”, {a: function() {return 2}}, {allowFunctions:
> true});// also returns “3”
>
>
>
> but:
>
>
>
> safeEval(“1 + a()”, {a: function() { return 2}});// throws whatever
> you want because “allowFunctions” is denied
>
>
>
> etc.
>
>
>
> Note that local variables are specified in argument. Also note that
> “options” mainly gives/denies permissions. I’m not sure if we should be
> whitelisting or blacklisting features there though, or a mix of default
> enabled and disabled ones...
>
>
>
> Very incomplete, but as for inspiration (and very useful to me):
> https://www.npmjs.com/package/@doodad-js/safeeval
>
>
>
>
>
> Claude
>
>
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-6456435073511435867_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Inline ES Modules

2018-06-20 Thread Mike Samuel 
On Tue, Jun 19, 2018 at 9:50 PM Darien Valentine 
wrote:

> Aha! Thanks. I think I get what you mean now.
>
> Let’s say I have this CSP:
>
> ```
> content-security-policy: script-src 'nonce-foo'
> ```
>
> And I have this in my document:
>
> ```
> 
>   import 'data:text/javascript,console.log(`bar`)';
> 
> ```
>
> Then the browser could theoretically ignore the absence of 'data:' in the
> CSP safely because the import statement here is part of a nonce-allowed
> script. And the unsafety is adding `data:` to the CSP (which would then be
> available for third party scripts I might also allow), not using `data:` in
> my own trusted modules; and there is a minor bit of unsafety associated
> with dynamic import, but it’s not in the same league as the unsafety
> potentially implied by a blanket permission for all `data:` URI sources.
>
> I was surprised that this nuance was considered. I figured it just blindly
> asked "is this source permitted by the CSP" without taking into account
> whether the trust from a parent resource could be implicitly extended. But
> I see you’re totally right:
>
> ```
> 
> 
> 
>   import 'data:text/javascript,document.open();document.writeln(`
static
> import of data URI module worked
`)';
>   document.writeln(`
nonce module worked
`);
>   import('data:text/javascript,document.writeln(`
dynamic import of data
> URI module worked
`)');
> 
> ```
>
> demo: https://necessary-hallway.glitch.me/
>
> All three seem to work! Very cool.
>

https://github.com/w3c/webappsec-csp/issues/243 : "Any protection against
dynamic module import?"
captures the discussion on this.


> Sorry for the diversion from the main topic. This was really interesting
> and I appreciate the explanation.
>
>
> On Tue, Jun 19, 2018 at 8:58 PM Mike Samuel  wrote:
>
>> Sorry for the confusion.
>>
>> Nonces are just for elements with url attributes.
>>
>> I mentioned nonces to point out that strict CSP policies can allow some
>> data: urls without having to explicitly whitelist or hash the entire
>> content.
>>
>> Separately I wanted to say that there is no incompatibility between the
>> goals of CSP and import statements that use a data: module specifier, since
>> we already trust the compilation unit and there's no actual network message
>> leaked.
>>
>> But there is a risk with the import operator since it's input is not part
>> of an already trusted input.
>>
>> On Tue, Jun 19, 2018, 8:22 PM Darien Valentine 
>> wrote:
>>
>>> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
>>> just for whitelisting inline script elements. How does one specify a nonce
>>> in association with a data URI? I’m having trouble turning up a description
>>> / example of how it would work. Or possibly I’m misunderstanding this quite
>>> a bit, hm ... I’m also confused by the relationship between import/import()
>>> and XSS that you’ve described.
>>>
>>> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel 
>>> wrote:
>>>
 CSP with data URIs is possible via nonce sources.  For data: module
 descriptors browsers could safely skip the CSP check since it doesn't allow
 XSS unless one can already specify an import statement which typically
 means one can specify arbitrary JS.  That argument doesn't extend to the
 import operator though so you'd have to tolerate assymetry there.

 On Tue, Jun 19, 2018, 7:57 PM Darien Valentine 
 wrote:

> Andrea: That is a really interesting approach. I would point out that
> using data URIs for js means the `data:` scheme has to be a permitted
> source for script-src. This allowance has roughly the same security
> implications as permitting `unsafe-eval`. I know most people aren’t using
> CSPs yet, but personally I’d be wary of a solution that makes it harder to
> adopt a strong CSP.
>
> A super dorky/tangential aside that probably doesn’t matter at all but
> ... I notice you used application/javascript for the media type. There’s a
> contradiction between the IANA media type registry and the HTML 5 spec 
> with
> regard to the "correct" media type to use for JS. RFC 4329 says
> application/javascript is the only value that should be used, while HTML
> says text/javascript is the only value that should be used. I believe (not
> sure though) that this is because it’s the most backwards-compatible 
> value.
> Given that the media types registry seems to be basically dead to web
> standards (if we follow the registry we can’t serve or post a bunch of
> media types acknowledged or defined by web standards at all, including
> image/webp, application/csp-report, etc) and the code has to run in a
> browser, I’d tend to think HTML is the better spec to follow ... though I
> guess when two specs contradict each other it’s hard to make an objective
> case for one being more authoritative. (I’d be curious if there’s a
> specific reason you know of to prefer to RFC

Re: Inline ES Modules

2018-06-20 Thread Sultan 
They would act akin to hoisted functions declarations in that regard, For
example

```
import {getPersonType} from School

if (Math.random() < 0.5) {
  module School {
export function getPersonType() {}
  }
}
```

Largely yes, the utility is in providing bundlers and authors with a
encapsulated order-independent "concat-able" standard format to output to,
considering the hurdles presented with the "waterfall of requests" problem
that can afflict current native ES modules.

Additionally there are aspects that bundlers have a hard time replicating
when using ES modules as an authoring format. Consider the following
example, where ES modules might maintain a "live" binding.

```
// a.js
import {b} from './b.js'

setTimeout(() => console.log(b), 400)

// b.js
export var b = 1

setTimeout(() => b++, 200)
```

A bundler on the other hand might be forced to produce static bindings.

```
var $b1 = 1

setTimeout(() => $b1++, 200)

var $b2 = $b1

setTimeout(() => console.log($b1), 400)
```




On Mon, Jun 18, 2018 at 4:04 PM, Mike Samuel  wrote:

> How would an inline module be imported?  Module descriptors are roughly
> relative URLs so can refer to a JavaScript source file, but it sounds like
> you'd need something more fine-grained to refer to an inline module.  Using
> fragments to refer to a passage within a document instead of a location
> might have unintended effects.
>
> Also, assuming that problem is solved, does the below mean anything
> if (Math.random() < 0.5) {
>   module School {
> export function getPersonType() {}
>   }
> }
>
> If not, if inline modules are defined eagerly, what advantages, besides
> making life easier for transpiler writers, would inline modules have over
> exporting frozen namespaces?
>
>
>
> On Sun, Jun 17, 2018 at 10:34 AM Sultan  wrote:
>
>> Are there any open proposals/discussions related to creating ES modules
>> inline? For example:
>>
>> ```
>> import getPersonType from School
>>
>> module School {
>>   export function getPersonType (person) {
>>   switch (person) {
>>   case 'Teacher': return 'A teacher'
>>   case 'Director': return 'A director'
>>   }
>>   }
>> }
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline ES Modules

2018-06-20 Thread Mike Samuel 
On Wed, Jun 20, 2018 at 10:44 AM Sultan  wrote:

>
> Additionally there are aspects that bundlers have a hard time replicating
> when using ES modules as an authoring format. Consider the following
> example, where ES modules might maintain a "live" binding.
>
> ```
> // a.js
> import {b} from './b.js'
>
> setTimeout(() => console.log(b), 400)
>
> // b.js
> export var b = 1
>
> setTimeout(() => b++, 200)
> ```
>
> A bundler on the other hand might be forced to produce static bindings.
>
> ```
> var $b1 = 1
>
> setTimeout(() => $b1++, 200)
>
> var $b2 = $b1
>
> setTimeout(() => console.log($b1), 400)
> ```
>

 Or recognize bindings that might be reassigned and use the mangled export
binding directly instead of introducing a local for the import bindings:

```
var $b1 = 1
setTimeout(() => $b1++, 200)

setTimeout(() => console.log($b1), 400)
```

Or allocate a cell for reassignable bindings:

```
var $b1 = [1]
setTimeout(() => $b1[0]++, 200)

var $b2 = $b1
setTimeout(() => console.log($b2[0]), 400)
```

No?

Maybe I'm treading on "sufficiently smart transpiler" territory but it
seems to me that live bindings can be handled simply with a bit of overhead
that can be often eliminated in the common case with only local analysis.

And to the degree that this is a problem, it's a problem as long as there's
a gap between inline module support becoming available and bundlers
end-of-lifing support for previous versions of EcmaScript as an output
language option.

Unless I'm missing something,  inline modules are unnecessary for live
bindings and insufficient given the need to support older versions as
output languages for at least some time.



Did you address my question about importing inline modules?  If so, I
must've missed it.



> They would act akin to hoisted functions declarations in that regard,

I'm also unclear what function hoisting has to do with module declarations
inside loops or conditionals if that's allowed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss