See inline Sent from my iPad
On 10.07.2011, at 19:40, Dale Newfield <d...@newfield.org> 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: http://api.jquery.com/jQuery.ajax/ >> 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 it. > >> 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: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
