Operator overloading

Brendan Eich brendan at mozilla.org
Sat Mar 24 12:52:20 PDT 2007

Hi Joe, you raise a good point about CSRF, but I think it is  
misdirected against the operator proposal. Have you had a chance to  
read http://developer.mozilla.org/es4/proposals/operators.html yet?  
Note that this is not "operator overloading" in the C++ sense. We are  
not add instance method overloading with dispatch based on argument  
types as well as the type of the receiver object (the |this| parameter).

See also http://developer.mozilla.org/es4/proposals/ 
normative_grammar.html for how ECMA-357 (E4X) syntax is reserved.

In ES3 + E4X and ES4, / and < either are binary operators, or lexical  
delimiters introducing regexps and XML literals respectively. This is  
already implemented in JS1.6+ and AS3. But the role of such  
characters can't be modified by any static operator method definition  
-- it is strictly determined by the grammar. In operator position (in  
an operator precedence parser), / and < are dyadic operators. In  
operand position, they start distinct lexemes.

Since the only way to define operators is by static class methods,  
and you can't extend existing classes with new static methods, the  
only hazard is that one can load E4X using a script tag across  
origins. This enables CSRF attacks on XML data inside firewalls which  
may lack any access control because the intranet designers assumed  
the firewall was enough. Such attacks are not possible with  
XMLHttpRequest given its current same-origin restricting. This  
problem is mitigated somewhat by E4X's basis in XML 1.0, its limited  
support in browsers, and its inability to load schemas or DTDs.

This is one good reason (we have others) for not folding E4X into ES4.


On Mar 24, 2007, at 12:15 PM, Joe Walker wrote:

> Hi,
> I blogged about a potential danger of operator overloading in JS2:
> http://getahead.org/blog/joe/2007/03/22/ 
> operator_overloading_in_javascript_2_and_a_potential_monster_csrf_hole 
> .html
> Kris Zyp made a very good point about unitary operators which  
> indicates that the risk probably does not exist. I hope he is right.
> The real worry here is that the designers of the language will, in  
> one spec, have to out-smart crackers for a long time to come. Once  
> websites start using a feature, it can't be easily removed. In my  
> opinion, this is a good case for a 'belt-and-braces' approach to  
> security.
> I also wonder if this technique could be used as a way of stealing  
> other data formats?
> Thanks,
> Joe.
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20070324/f0a7e32e/attachment-0002.html 

More information about the Es4-discuss mailing list