Hi,
I'm working on that issue, but despite the main problem I would like
to use JSONWriter to produce the output. I'm going to create Error
class that will contains the same structure as is now build by
JSONValidationInterceptor. It will wrap the keys and messages with
awareness of WW-2721.
Kind
We did an internal research on the issue with JSON and it looks like,
the arrays are only vulnerable, if output contains an object, it isn't
a valid JavaScript.
IE8, FF3, FF5, Chrome
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitur
On Wed, Jul 13, 2011 at 10:04 AM, Christian Grobmeier wrote:
> Exact. Because with comments it cannot be treated as application/json
Fair enough; comments aren't in the JSON spec, and:
http://blog.getify.com/2010/06/json-comments/
I'm with the blogger.
Dave
2011/7/13 Łukasz Lenart :
> 2011/7/13 Dave Newton :
>> On Wed, Jul 13, 2011 at 9:08 AM, Christian Grobmeier wrote:
>>> For the default value I would just avoid "application" before the
>>> slash, because I have experienced that the file is downloaded then.
>>> This cannot be easily spotted if you h
2011/7/13 Dave Newton :
> On Wed, Jul 13, 2011 at 9:08 AM, Christian Grobmeier wrote:
>> For the default value I would just avoid "application" before the
>> slash, because I have experienced that the file is downloaded then.
>> This cannot be easily spotted if you have jquery as a frontend.
>> Any
On Wed, Jul 13, 2011 at 9:08 AM, Christian Grobmeier wrote:
> For the default value I would just avoid "application" before the
> slash, because I have experienced that the file is downloaded then.
> This cannot be easily spotted if you have jquery as a frontend.
> Anything with "text/" before the
On Wed, Jul 13, 2011 at 9:08 AM, Christian Grobmeier wrote:
> For the default value I would just avoid "application" before the
> slash, because I have experienced that the file is downloaded then.
> This cannot be easily spotted if you have jquery as a frontend.
> Anything with "text/" before the
>> On 7/13/11 5:06 AM, Christian Grobmeier wrote:
>>>
>>> In addition to that I would like to see another content type in the
>>> response then "application/json" if it is in commented mode, like
>>> "text/ext-json".
>>
>> Since there's no "right" answer to what that alternative mime-type should
>>
2011/7/13 Dale Newfield :
> On 7/13/11 5:06 AM, Christian Grobmeier wrote:
>>
>> In addition to that I would like to see another content type in the
>> response then "application/json" if it is in commented mode, like
>> "text/ext-json".
>
> Since there's no "right" answer to what that alternative
On 7/13/11 5:06 AM, Christian Grobmeier wrote:
In addition to that I would like to see another content type in the
response then "application/json" if it is in commented mode, like
"text/ext-json".
Since there's no "right" answer to what that alternative mime-type
should be, I would suggest it
Rene,
with your post you spoke from my heart - +1 & thanks.
> 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
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.
2011/7/12 Wes Wannemacher :
> However, in our JSON plugin, we have a JSON marshaller that is much
> more capable. Personally, I think we should take the marshaller (or
> potentially the whole plugin) and move it into core, where
> JSONValidationInterceptor lives. Then, leverage the marshaller insid
+1
On Tue, Jul 12, 2011 at 12:09 PM, Wes Wannemacher wrote:
> Lukasz,
>
> One thing that has bugged me for a while is that the source of this
> discussion is this class -
>
> http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/validation/JSONValidat
+1
On Tue, Jul 12, 2011 at 12:09 PM, Wes Wannemacher wrote:
> Lukasz,
>
> One thing that has bugged me for a while is that the source of this
> discussion is this class -
>
> http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/validation/JSONValidat
Lukasz,
One thing that has bugged me for a while is that the source of this
discussion is this class -
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/validation/JSONValidationInterceptor.java?view=markup
Which, you will see when you pull it up
Hi again,
I wrote a short blog post how one can deal in jQuery with the Struts 2
returning /* */ json.
http://www.grobmeier.de/json-is-insecure-make-struts-2-and-jquery-vulnerable-safe-12072011.html
In addition I made a similar option available to jjson.googlecode.com
Struts 2 plugin.
I just wan
> Thanks for all the comments and links, now I've got better overview
> what's the real issue here. My idea was the same, to add some flag to
> enable / disable comments in the output with default to true.
I could not find the place but as this is not standard json the
content type of the response
Thanks for all the comments and links, now I've got better overview
what's the real issue here. My idea was the same, to add some flag to
enable / disable comments in the output with default to true.
I'm going to implement it till weekend, if not, Dale you're welcome to
do this as I'm going for sh
The patch applied is not backwards compatible, and will break existing
sites if they upgrade.
Both JSONResult and JSONInterceptor support a wrapWithComments
parameter...I think it most sensible to put the same parameter on
JSONValidationInterceptor. If we don't do that and default it to true,
>> 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 Obj
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 suggest
>> - 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 impor
On 7/9/11 2:36 PM, Christian Grobmeier wrote:
- 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.
- don't use GET as your method
I believe that would prot
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
Below are a few (of many that I found with a simple google search)
explaining the issue in detail. Basically the problem is that
If I recall correctly, this was done to help address information
leakage. Meaning if you're logged into a web application and also
visiting a page on another website, that other page could have a script
tag pointing at your web application, resulting in that data being added
to the page scope,
>> Sorry to ask, what is this issue proposing? To accept comments in json
>> strings?
>>
>> I checked specs at http://www.json.org/, but they do not mention
>> comments at all.
>
> To remove comments ;-)
ah yes got it
Yes they should be removed - I don't know a single json de/en-coder by
min
2011/7/8 Christian Grobmeier :
>> Is this still relevant ?
>>
>> https://issues.apache.org/jira/browse/WW-3545
>
> Sorry to ask, what is this issue proposing? To accept comments in json
> strings?
>
> I checked specs at http://www.json.org/, but they do not mention
> comments at all.
To remove co
> Is this still relevant ?
>
> https://issues.apache.org/jira/browse/WW-3545
Sorry to ask, what is this issue proposing? To accept comments in json strings?
I checked specs at http://www.json.org/, but they do not mention
comments at all.
-
30 matches
Mail list logo
