Re: Comments in JSON
- don't use javascript arrays to return as a json string It really doesn't matter if it's an array or object, if it's valid json that the browser will attempt to execute it's vulnerable. http://haacked.com/archive/2009/06/25/json-hijacking.aspx The fact that this is a JSON array is important. It turns out that a script that contains a JSON array is a valid JavaScript script and can thus be executed. A script that just contains a JSON object is not a valid JavaScript file. 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 mentioned to put everything into a js comment. This breaks the protocol definition and will cause jQuery to fail (and probably others). If it's doing XHR, I'm certain you can insert a filter to make it work either way, but making the result configurable doesn't seem to be an unreasonable request. I still suggest that the default behavior is to protect users' data. 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. For sure this issue would drive me crazy. It is a more philosphical debatte. Should a framework provide standards and the user decides how he applies security? Or does the framework decide between lots of options about the users security and break the standards? As a Struts user, this are my expectations: If you choose the latter one (even when configurable) you should provide information on what you have done, why it is done and how you can work with this security standard in common tools like jQuery, Prototype, Dojo etc. I, as a user, want to make my way quick through everything. Sometimes I don't care on security (prototype), sometimes it is not necessary (internal app, non sensitive data). If I care, I can always read the security docs of Struts. If you choose to stick with standards, you should write a page about it and the user then needs to learn himself how he can achieve this. As you have guessed, I am more the standards and security docs guy. In addition a Struts json plugin should allow crossdomain ajax by default for POST only, GET should be enabled by user interaction. The plugin doesn't care, it's the configuration that determines when you use the interceptor or result. Is the configuration POST or GET by default? Or must it be configured in any case by the user? Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
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. 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
Re: Move deprecated plugins to archive
On Thu, Jun 30, 2011 at 4:12 AM, Johannes Geppert jo...@apache.org wrote: What about further development as a plugin outside of the Struts Project? We can create a project at Google Code or Github like the jQuery Plugin. Who is we? If we is a group of Struts committers, why would we take the code somewhere else, rather than working on it where it is now? If we isn't Struts committers, then they can take the code and do what they will with it, under the terms of the Apache License. The caveat in the latter case is if there is an intent to bring the code back to the ASF later. In that case, there just needs to be an assurance of code provenance when it comes back (e.g. an iCLA mechanism), and then it would need to go through a software grant or some such process to bring it back in. Before someone goes off and creates a separate project, though, it'd be interesting to hear why we think contributors will appear if the project is elsewhere, when they have not done so here for the last several years. (Or am I mistaken and we do have patches attached that are not being applied?) -- Martin Cooper Johannes - web: http://www.jgeppert.com twitter: http://twitter.com/jogep -- View this message in context: http://struts.1045723.n5.nabble.com/Move-deprecated-plugins-to-archive-tp4528259p4538454.html Sent from the Struts - Dev mailing list archive at Nabble.com. - 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
Re: Comments in JSON
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: 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. 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 problems. 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 data. 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? Cheers, Christian 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 -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
