Dale, you gave me a very interesting lecture at this evening, thank you very much for the links.
I have learned 2 things: - don't use javascript arrays to return as a json string - don't use GET as your method You mentioned to put everything into a js comment. This breaks the protocol definition and will cause jQuery to fail (and probably others). My suggestion is to let the user decide if he wants to enable this feature or not. I think a json plugin should send protocol conform return statements, and if somebody wants that security, he should enable this own his own. In addition a Struts json plugin should allow crossdomain ajax by default for POST only, GET should be enabled by user interaction. Cheers Christian On Sat, Jul 9, 2011 at 5:34 PM, Dale Newfield <d...@newfield.org> wrote: > Below are a few (of many that I found with a simple google search) > explaining the issue in detail. Basically the problem is that <script /> > tags don't abide by the same-origin policy, so if your response to a GET > request is a valid json object, that data can be fetched by a script tag in > pages on other sites, and then sent back to that other site without the user > knowing. Wrapping the response in a comment protects that data. > > -Dale > > http://directwebremoting.org/blog/joe/2007/03/06/json_is_not_as_safe_as_people_think_it_is_part_2.html > > http://haacked.com/archive/2009/06/25/json-hijacking.aspx > > http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx > > http://www.yuiblog.com/blog/2007/04/10/json-and-browser-security/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > -- http://www.grobmeier.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
