[thelist] ajax, javascript libraries - security.

Matt Warden mwarden at gmail.com
Sun Apr 15 10:24:43 CDT 2007


On 4/13/07, trevor <trevor at intospace.ca> wrote:
> but OTOH, i think their premise was not "all json is bad".   their premise
> was "to raise awareness"  that there are proper and improper ways to handle
> this type of coding.   it's a very general thing, so they also didn't
> present any in depth discussion of best practices.
>
> so, i'm niether attacking nor glorifying their paper,  i'm just asking if
> some pro's here could recommend their favourite resources for ajax security
> best practices, and  json best practices.  there are lots of results to plow
> through from a general search -  i thought i would get some recommends here,
> that's all.

I re-read the paper; I still think the answer is clear: don't use
JSON. Using a data format with the capability of defining behavior
never made any sense to me. From what I can tell, developers use JSON
so they can avoid having to walk the DOM of an XML response.

Use a format that must be parsed and you avoid this attack completely.
This means XML or JSON that requires parsing (i.e., surrounded by /*
and */ that must be removed, or the approach Google took by including
a first line of while(1); which must be removed or it would send the
JS interpreter into an infinite loop).

Another option is to have the server side inspect incoming requests
and only respond to those that are legitimate. While this should be
done regardless, I'm not naive enough to think that developers
actually do it, or even will do it given this paper.

Your other option is, like the paper suggests, to not accept GET
requests on the server-side. This is easy to do with, say, Java
Servlets. It takes some extra work in most other languages, so [insert
previous point about no one doing it].

Bottom line: just use XML, and tell your dev team to use XML. Simple,
clear-cut fix. Blindly eval'ing anything that came your way in the
response was always a bad idea, and now we have a paper on one reason
why (admittedly, not the reason I was thinking of).


-- 
Matt Warden
Cleveland, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.



More information about the thelist mailing list