[thelist] ajax, javascript libraries - security.

Matt Warden mwarden at gmail.com
Sun Apr 15 14:13:22 CDT 2007

On 4/15/07, Charles <lists07 at wiltgen.net> wrote:
> > Using a data format with the capability of defining behavior never made
> any sense to me.
> JSON doesn't have that capability.  JSON is just a simple subset of
> JavaScript's object notation, and it's best not to internally equate the
> two.
> Obviously, anyone eval()-ing anything that might contain untrusted code is
> asking for it.
> > Bottom line: just use XML, and tell your dev team to use XML.
> That might be good advice if you're not doing rich internet applications.
> If you are, then JSON is often a better choice.
> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=060ca7c3-b03f-41aa-937
> b-c8cba5b7f986
> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=39842a17-781a-45c8-ade
> 5-58286909226b

Your two points contradict themselves. Either we are going to take
advantage of the fact that JSON can be interpreted as JavaScript in
the page context or we are not. If you agree that eval()-ing returned
JSON (which is only one way to do this -- the XML v. JSON articles
describe the other) is a bad idea, then you must treat it as a simple
data format and it is subject to the same restrictions that XML is.

If you think that eval()-ing or using the script tag workaround is a
good idea or a benefit of JSON, then there is the potential for
behavior to be included (regardless of whether some abstract standard
defines JSON as a subset of JS). Your links describe the script tag
workaround as a great feature of JSON. The article we are discussing
points out that this great feature assumes that it will never be used

Matt Warden
Cleveland, OH, USA

This email proudly and graciously contributes to entropy.

More information about the thelist mailing list