JSON and Security

[vunet]

When implementing JSON as a form of data exchange between server and
client, what security measures do I need to consider? For example, I
have XMLHttpRequest returning JSON text from the server and eval()
converts string to the JavaScript object. I heard about problems with
"eval" and idea of using "magic cookies" to avoid attacks. Anyway,
what should I consider?
Thanks.

[Stevo]

vunet wrote:

When implementing JSON as a form of data exchange between server and
client, what security measures do I need to consider? For example, I
have XMLHttpRequest returning JSON text from the server and eval()
converts string to the JavaScript object. I heard about problems with
"eval" and idea of using "magic cookies" to avoid attacks. Anyway,
what should I consider?
Thanks.

Quite a few topics on it here:

http://www.google.com/search?q=json+security+eval

[Krukow]

On 14 Feb., 21:04, Stevo <[e-mail]:

vunet wrote:

When implementing JSON as a form of data exchange between server and
client, what security measures do I need to consider? For example, I
have XMLHttpRequest returning JSON text from the server and eval()
converts string to the JavaScript object. I heard about problems with
"eval" and idea of using "magic cookies" to avoid attacks. Anyway,
what should I consider?

This blog post (including the referenced paper) and the following
discussions are quite useful:

http://www.schneier.com/blog/archive...pt_hija_1.html

The above (including links) is where to go, but my understanding is
the following:

Basically, there isn't anything insecure about JSON by itself; just
make sure you check that it is actually valid JSON before you eval it!
However, the combination of a certain type of attack called Cross Site
Request Forgery (CSRF) and JSON is particularly unfortunate. If you
can stop CSRF (and XSS) in your web application there should be no
problems using JSON. The "magic cookies" you heard about are probably
about stopping CSRF, and as such have nothing to do with JSON.

However, if you are not sure that you can stop CSRF attacks, then you
might have slightly more security by using (say) XML instead of JSON
as the data exchange format, as this removes a few JSON specific
attacks (though XML alone with no CSRF protection isn't secure either,
in general). The most important question to answer first is: Is the
data being exchanged "public" or "sensitive"? In case it is public,
you probably don't have to worry about the data-exchange format too
much.

Regards,
- Karl