Operator overloading in Javascript 2 and a potential monster CSRF hole
I noticed that Javascript 2 might include operator overloading, including (at least) the ability to overload the < and > operators.
Operator overloading is really useful if you want to write a Complex number class, and really annoying when someone else wants to flex a newly learn skill and uses it for something totally inappropriate. Since authors of Complex number classes are less common than inexperienced programmers, I'm not keen on the idea in general purpose languages.
However, opinions about programming languages aside, I think that operator overloading in Javascript could turn out to be a really bad idea for a totally different reason.
The ultimate CSRF hack, when Javascript 2 comes out, might just be to redefine operators to make XML (or even HTML) a valid language.
You could then steal fairly much steal any cross-domain data by doing a script-tag include on an XML/HTML data source.
I really hope someone has thought of this...
Update: I can see that I didn't explain myself very well, so a quick update might be needed.
If you can overload the < and > operators then it might be possible to do so in such a way that HTML or XML becomes a valid bit of Javascript. This is more likely to be possible with known schema like HTML.
So how would this create a huge security hole? Simply because it would allow an attacker to use a script tag to include some HTML and then read the data using a combination of overloaded < and > operators and the Array/Object data stealing methods.
Currently CSRF is restricted to write-only exploits, and the standard way of protecting yourself includes using authentication data in a hidden form field. If an attacker could read this data too, then the standard protection against CSRF would fail. Also you could use this to steal data from intranets and, I'm sure, there are many other options.
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 the feature, it can't be easily removed.
Re: Operator overloading in Javascript 2 and a potential monster CSRF hole
The issue here isn't about whether the language stops programmers from shooting themselves in the foot; it's more about whether the new language feature breaks the web:
Currently, you can make use of script src attributes to perform CSRF on and steal information from applications which provide JSON data at predictable URLs. This is limited to JSON data / valid javascript as the javascript parser will baulk at anything else.
If, however, you're able to override operators such as <, > and / then XML and HTML become potentially valid JavaScript, so you can potentially put hooks into various Javascript constructors (see this post) to steal data in other forms.
Re: Operator overloading in Javascript 2 and a potential monster CSRF hole
If you still have concerns after reading the proposal, you should drop a note to the discussion list -- I'm sure they'd love to hear your insights.
Re: Operator overloading in Javascript 2 and a potential monster CSRF hole
Re: Operator overloading in Javascript 2 and a potential monster CSRF hole
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.