1

So I was looking through the Mootools docs for Request and noticed a somewhat recent comment posted that reads the following...

"Be aware of XSS vulnerability: Default value for secure is falsy, which means that JSON.decode("alert(document.cookie)") shows a popup !"

The documentation for the JSON.decode method says this:

JSON Method:Decode

Converts a JSON string into a JavaScript object.

Syntax:

var object = JSON.decode(string[, secure]);

Arguments:

string - (string) The string to evaluate.

secure - (boolean, optional: defaults to false) If set to true, checks for any hazardous syntax and returns null if any found.

Returns: (object) The object represented by the JSON string.

So, based on the documentation, it's pretty obvious to me that the JSON.decode method is set to be "insecure" by default. My question though is what (if anything) that has to do with XSS, and whether that comment from the top of my post is valuable. Assuming you're using Mootools in the frontend, and you trust the address you're making your AJAX call to, how could this be a XSS security exploit?

http://mootools.net/docs/core/Utilities/JSON

Funktr0n
  • 1,711
  • 2
  • 16
  • 23

2 Answers2

2

The problem here is eval().

Since "back in the days", before JSON.parse() came to life Mootools used eval to return the parsed JSON. So the problem here is the same as discussed here about eval().

If you write code just for modern browsers, go for vanilla JSON.parse(). If you need crossbrowser down to IE6, then Mootools does the job for you ™ Mootools gives powerfull tools for developers, turn on the secure option/parameter if you don't want to use eval.

Community
  • 1
  • 1
Sergio
  • 28,539
  • 11
  • 85
  • 132
  • I guess I just still don't see how this could be considered a XSS vulnerability... can't any user eval() anything from the browser at any time? The only thing I could see happening here is if you made an AJAX request to an untrusted source (or one that was compromised in one way or another) and it returned some dangerous code. But if you don't trust your source or a remote server was compromised somehow, I don't think there's anything you can really do about that... I suppose you should avoid catastrophe for your users though if you can avoid it. Still don't think it's really XSS. – Funktr0n Feb 20 '14 at 20:52
  • 1
    @Funktron Like Sergio already pointed out the problem is that the MooTools fallback uses eval to "parse" the JSON String. Now imagine that you serialize and deserialize user input or URL parameter with it which can lead to XSS vulnerability. – n3on Feb 21 '14 at 10:52
  • It can't lead to a vulnerability unless you change your data on the server somehow. Like I said earlier, anyone could eval anything they want in their browser... you don't have any control over that -- you never did. – Funktr0n Feb 23 '14 at 21:36
  • 1
    @Funktron i'm not sure if you understand what XSS vulnerability means: http://www.thegeekstuff.com/2012/02/xss-attack-examples/ It's not necessary to get the JSON data from the server. It can come from anywhere, and the problem isn't the user self executing something. The problem is that the user gets tricked that his browser executes something which he isn't aware of. Then the attacker can manipulate the page for this "specific" user which leads to a very severe issue. And for the user it looks like, you as website provider, are doing this to him. – n3on Feb 25 '14 at 14:38
  • Sorry, but this is all very mysterious. All you've explained is that the user was "tricked" and executed something he wasn't aware of which created a "very severe issue". Please give me a specific example where using eval() in my front-end code would lead to a XSS vulnerability if my server hadn't been compromised or otherwise designed without regard to security. The link you sent me doesn't provide any such example. – Funktr0n Mar 07 '14 at 18:46
  • @Funktron http://jsfiddle.net/DkMvR/ use window.location for the url instead and you have your xss scenario. – n3on Apr 28 '14 at 18:28
1

After reading pages of documentation and learning everything I can about XSS, it seems to me that the only way to introduce a XSS vulnerability solely with front-end javascript is to use that code to perform "server-like" decisions. What I'm referring to is what is called DOM-Based XSS, whereby your front-end js code takes parameters from either the URL query string, or some other unattached resource and attempts to do something with that input without properly sanitizing and/or escaping it beforehand.

This really has nothing to do with eval() though, and has everything to do with how you design your "site experience" with regard to responses/requests. The way you avoid XSS is by making sure that your code never loads/sends anything it can't trust. eval() is just a function.

Funktr0n
  • 1,711
  • 2
  • 16
  • 23
  • 1
    `+1` for your answer. Anyway, just FYI __[today went to master](https://github.com/mootools/mootools-core/commit/2769c9d6f3d7ac8421a57f453ecccd1b7f360bfc)__ a correction to this issue. It will be shipped with MooTools 1.5 due to be released the next days. – Sergio Mar 17 '14 at 15:40
  • Cool! Glad to see MooTools for the frontend is still alive and well -- I had thought at one point that the project had shifted to Node.js and MooTools Prime – Funktr0n Mar 18 '14 at 12:33