Thanks for the reply.
I'm certainly no expert on JS2, but your answer does seem like a
belt-and-braces approach for now.
Joe.
On 3/24/07, Brendan Eich <brendan at mozilla.org> wrote:
>> 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.htmlfor 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.
>> /be
>> 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>>>> _______________________________________________
> 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/d7589367/attachment-0002.html