Verify JavaScript before using eval()

[Frinavale]

Apparently I have a lot of questions today regarding JavaScript security.

I've implemented a JavaScript Object that intercepts page submits (postbacks) and then displays a UI prompting the user to confirm(yes)/deny(no)/cancel(close UI/cancel submit) their action.

There may be additional JavaScript methods to execute before displaying the UI and may be additional JavaScript methods to execute upon closing the UI.

I'm thinking about passing these additional JavaScript methods from the server to the JavaScript Object using "properties ".

There's a little magic here because I'm not entirely sure how the data (the properties) is passed from my .NET Server code to my JavaScript Object. I'm assuming that there is a JSON Object being used behind the scenes....I'm going to look into this on my own....

I am wondering about the risks of using the eval() method with regards to JSON Objects. I'm quite new to JavaScript and so I'm not entirely sure how to secure my Objects.

The way I see it (assumption about using JSON made):

• Server sends JSON Object to client:
  • client populates my JS Object's properties w/data supplied
  • JS Object uses eval() method to executed additional JS methods

If the JSON Object were captured and modified during transport, then my JavaScript Object may end up executing code that isn't my own.

Is there some way (a toolkit or other JavaScript library which you would recommend that can check hashes or something) to verify that the JavaScript has been provided by my code?

Is this type of attack easy to do (is it high risk)?

Is there something other than the eval() method that I can use that is safer?

Are there any other risks that I should be aware of?

I know that this is a lot to ask but I'm pretty much looking for any keywords/concepts that I can research before I start implementing this solution. Your thoughts on the topic would be greatly appreciated.

Thanks a lot,

-Frinny

[Dormilich]

I've not done much with JSON (I'm using WDDX), but if you serialize an object you do not transmit the methods (and thus do not use eval()), i.e. you need to have the class definition where the methods are stored already in the script and the objects are deserialized using the transmitted properties only.

from what I know there are different JSON deserializers available (at least 3)

[Frinavale]

@Dormilich
What??
You've completely lost me.

[Dormilich]

objects are usually sent serialized (you only submit the data (properties) and therefore need the "class definition" on the receiver).

acoder mentioned to look at the JSON parsers instead of using eval().

[Frinavale]

I'm still reading through the links (of the links) that acoder had posted.

Now, I'm not sure I'm ready to jump into using JSON before I completely understand how it works. (I starting having a lot of fun with it a couple of weeks ago...I was very impressed with what I could do using JSON and AJAX)

The parseJSON() method looks like it's going to fix a bunch of security risks inherent to JSON's dependency on JavaScript's eval() ...but there are a lot of security topics (that I was not aware of before now) that I'm going to have to keep in mind while using JSON.

I wonder if the AJAX.NET library uses the parseJSON() method? I am having a very hard time finding out what exactly is going on behind the scenes with regards to how the data is transferred from the Server to the Client.


I have a feeling that the "Same Origin Policy" is going to cover a lot of the concerns that I was having with my particular object....but I'm still not sure how to detect a man-in-the-middle attack.

[acoder]

In case anyone else following this thread is wondering what those links were[*], here they are:
JSON in JavaScript
JSON - Wikipedia
Basically, use a JSON parser instead of eval().
[*] deleted the post as I saw Dormilich had responded.

[rnd me]

man in the middle?
the only way to stop that is https.

if you are serving your own content, there's no reason eval cannot be used.
you are serving the whole page in the first place, right?

if you are talking about large amounts of data, remember that eval is WAY faster than a JS-based parser would be.

jsonp demands a little more care than json, only because 3rd party websites will be able to use free-range javascript to grab your data. anyone could still use curl to get your non-jsonp json, they just can't easily and cheap pass along the ability to do so, thanks to the SOP...

remember, jsonp uses eval, only json via ajax can be parsed as described...