Friday, March 23rd, 2007
Operator overloading in Javascript 2 and a potential monster CSRF hole
Joe Walker is thinking about security again, and is worried about Operator overloading in Javascript 2 and a potential monster CSRF hole.
In question is the proposal of operator overloading in JavaScript 2 that could allow someone to override <, > and / to do some evil things.
JAVASCRIPT:
-
-
<script type="text/javascript">do stuff</script>
-
Think you could do something with that?
2.9 rating from 23 votes
… ehr … implementation is inside a class, not global … however, You should redefine (???) a generic Object class but the problem is that if You can inject javascript You can do everything You need, with or without operator overloading, imho.
I prefere more power to developers that know how to use some feature, not broken or fake one (grow up JavaScript, please grow UP!)
The only real “security” that i am worried about with AJAX is the “keylogging”.
Copying what i saw in an article, me and a few of my friends decided to attempt keylogging visitors who use the search engine on our site using a MYSQL database.
We let it be for a few days, and it worked.
You all see forums that run on vBulletin and ipb that automatically check to see if your username is taken, if your passwords/emails are already registered.
It wouldent take a genious to recode that to copy your password unencrypted.
Brendan Eich has commented on the ES4 discussion list that this is not of major concern.
Never mind then, back to what you were doing :)
E4X (ECMA-357) is a concern, though. As specified, it enables XSS reading of .xml files from behind firewalls, etc. — CSRF too but that requires other flaws.
Firefox does not implement E4X as specified, however; you cannot override the XML constructor and change how there is interpreted. This saves us from helping web app authors make mistakes that create the CSRF and XSS JSON holes that Joe Walker has blogged about.
For belt-and-braces (and this should be in the standard), we are going to reject E4X content read via tags that does not have the right MIME type. And E4X is not required by ES4, but we can tighten up MIME type rules in ES4 (a novelty — no one defined registered Internet Media Types for JS back in the HTML 4 daze).
Anyway, the ES4 operator proposal is innocent here. And it’s a good thing, so don’t pick on it ;-).
/be
Could someone enlighten me: why overloaded operator is less secure then regular method call?
Personally, I like Scala/Ruby syntax where all operators are in fact method calls, and syntax of method call let us treat method as operator — as a result developers have neat options to build own DSL-s.
VS
I don’t think that the binary greater-than and less-than operators (> and http://www.thetruetribe.com/2008/03/javascript-method-overloading.html
I took inspiration from John Resig’s addMethod() function that allows you to overload based on number of arguments. I wrote a version that allows you to overload based on types, although it is rather unwieldy. I don’t think I would use it in production code but it’s interesting from a theoretical point of view.
Sorry, my comment got mangled. What I meant to say was that I don’t think the greater-than and less-than operators (> and <) can be overloaded and changed from binary to unary operators if the based on the EcmaScript 4 proposal. Anyway, that’s not what I get out of it.
I also wanted to post a link to an article I wrote proposing a homegrown solution for method overloading in JavaScript:
http://www.thetruetribe.com/2008/03/javascript-method-overloading.html