struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: Comments in JSON
Date Sun, 10 Jul 2011 18:28:30 GMT
>> 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.
> "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"

Well, no, I haven't made a google search but yes, I read all the
articles and simply forgot that there was something about objects.

>> 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.

You missed my point here. Yes, one can extend jQuery. Yes, one can
write cool stuff with JavaScript.

>> 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.

OK, if you want to go that way. The vulnerable you brought up is - at
least in my understanding - a JavaScript problem.

So, what do you want to do with all the other JavaScript exploits out
there? How do you want to deal with Java-related security problems?
How do you want to take care on DNS problems? Do you really want to
take care on all language/environment problems out there?

First, a framework should implement protocols and specifications
-correct-. Second it can make suggestions to potential security

You simply cannot break a specification upon which the whole world
relies. If you promise to return JSON, return JSON. Otherwise call it
"Extended JSON" or whatever.

> 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

Yes, and there are plenty of developers who are working on
non-sensitive data apps. Or on internal apps.

You say, Struts would be "defaulting to an insecure mechanism". But
you could also say, it is following the protocol and send the expected

> and at the end of the day the framework will get blamed for it.

To my knowledge you cannot blame Struts for delivering correct JSON.
You can blame JavaScript for making exploits possible. If I have a
security whole in my Tomcat installation, I cannot blame Struts just
because it is running on Tomcat.

After all there will be tons of users claiming about the fact that
Struts does not return valid JSON by default.

>> 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.

To my knowledge this is an discussion about making the JsonPlugin to
return non-standard Json by default or not. I have expressed my
expectation if you do it the one way or the other and that is not a
separate question. In fact, what the framework user is expecting and
what he wants is the crux of this discussion.

>  Struts is an open source project.  If you think there should be a page that
> doesn't yet exist, please write it and contribute it.

Sure, actually I know what Open Source is. I would write a security
page if I would have the competence. But I am not a security expert
and so I can only contribute little to this page.

And while we are at it, not even the "comments yes/no" should be
configurable. One should be able to configure a string to his likings.
Maybe at one day somebody finds an exploit to work with that data even
when commented?


>> 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