struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Gielen <>
Subject Re: Comments in JSON
Date Wed, 13 Jul 2011 08:20:06 GMT
See inline

Sent from my iPad

On 10.07.2011, at 19:40, Dale Newfield <> wrote:

> On 7/10/11 4:34 AM, Christian Grobmeier wrote:
>> Maybe there are other exploits, but only know what you sent as links.
>> And those are saying you need a JSON array because JSON objects are
>> not valid js statements.
> You clearly didn't read all the links I included, or do your own search as I suggested.
 The following statements are from another page in that short list of links I included:
> "Yesterday, I blogged about how to steal data from JSON by overriding the Array constructor.
Today, we break into Objects too."
> ...
> "So now you can steal data from any JSON object"
>> I just checked:
>> jQuery does XHR (wrapped in jqXHR object), but I would not have a clue
>> how I could remove that comments.
> Then maybe you should find a clue.  JavaScript is an incredibly dynamic language.
>> It is a more philosphical debatte.
> Agreed.  The core of the debate are who are the "users" that we as framework developers
should be protecting.  I claim that they are the people using the applications built using
the framework, not the people developing those applications.  You are free to develop insecure
tools for those users using this framework if you so choose, but I want you to have to make
a concrete decision to do so.  Your statement "If I care, I can always read the security docs
of Struts." illustrates that there are plenty of developers that won't bother to read the
docs unless something isn't working as they expect, and therefore if we default to an insecure
mechanism, their users' data will be insecure and they won't know anything about it, and at
the end of the day the framework will get blamed for it.

I see your point here. Depending on what level of tooling the framework is targetting, there
are different answers to the question what level of protection one wants to establish.
Say we were the Vaadin or *Faces project, I would agree that we would like to provide end-to-end
protection, as we'd provide a specific stack to generate web based UIs. On the other hand,
frameworks like Spring MVC or, well, Struts 2 are generic toolboxes for web development. In
case of Struts 2 developing web based UIs with the tag system is just one of many more usecases.
Developing backend services for your GWT, Flex or JQuery based app is a common and supported
option as well.

I think the S2 is designed as a programmer's tool with extreme flexibility covering varios
levels of the web stack, and when it comes to the user role discussion, I'm clearly on the
side that our users are the developers working with the framework, and actually the end-users
are their "customers". Nevertheless, we should not stop to have both in mind, but on concurring
interests I would value the developer's interest higher as far as it comes to flexibility
vs. deciding to not allow him to shot his foot.

Another point is: that it is really actually not a Struts problem, but a browser and general
technology problem. You want that fancy JSON stuff? Be sure to understand what you are doing!
Just as you have to if you are using Jersey, Restlet or Spring MVC.

I know we have a slight problem with RTFM, as we see in our mailing lists on a daily basis.
On the other hand we managed already to provide prominent notice for important information,
such as with the development mode setting, which we put in the console log.

So let's say we would provide prominent notice on application startup, level INFO or even
WARN. In case of uncommented JSON activated, say "WARNING: be sure to have read http://.../General+JSON+Security+Considerations.
Maybe you want to limit to POST requests only". In case of commented-mode, say "You are running
the JSON plugin in safe mode, which might impose incompatibilities to consuming services.
Be sure to read blablabla..."
This is meant regardless to what the default setting would be, which is a seperate discussion
then - as for me, I'd tend to standards rather than safe mode. 

Could this be a way to go?

>> you should write a page about it
> I will not claim that the documentation of this "feature" exists or is clear, but that
is a separate question than that of how it should behave.  Struts is an open source project.
 If you think there should be a page that doesn't yet exist, please write it and contribute
>> Is the configuration "POST" or "GET" by default?
> The configuration of your struts.xml which specifies the interceptors and result types
that your actions will use does not by default include json.  If you want to add in those
interceptors or results, you should learn how they work, and configure them appropriately.
> -Dale
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message