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.
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
2011/7/12 Wes Wannemacher w...@wantii.com:
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
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
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
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 be
2011/7/13 Dale Newfield d...@newfield.org:
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
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 slash
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 slash
sending, loose when receiving doesn't really work :/
I think, it's just in case of wrapped in comments JSON ...
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl
it now, I suppose. Even the usual be
strict when sending, loose when receiving doesn't really work :/
I think, it's just in case of wrapped in comments JSON ...
Exact. Because with comments it cannot be treated as application/json
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
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
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
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
+1
On Tue, Jul 12, 2011 at 12:09 PM, Wes Wannemacher w...@wantii.com wrote:
Lukasz,
One thing that has bugged me for a while is that the source of this
discussion is this class -
+1
On Tue, Jul 12, 2011 at 12:09 PM, Wes Wannemacher w...@wantii.com wrote:
Lukasz,
One thing that has bugged me for a while is that the source of this
discussion is this class -
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
- 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.
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
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.
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
Below are a few (of many that I found with a simple google search)
explaining the issue in detail. Basically the problem is that script
/ tags don't abide by the same-origin policy, so if your response to a
GET request is a valid json object, that data can be fetched by a script
tag in pages
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
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
Hi,
Is this still relevant ?
https://issues.apache.org/jira/browse/WW-3545
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
-
To unsubscribe, e-mail:
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
2011/7/8 Christian Grobmeier grobme...@gmail.com:
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
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
mind which
30 matches
Mail list logo