juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Lenart"<lukaszlen...@apache.org>
Subject Re: Security
Date Tue, 14 Nov 2017 10:00:21 GMT
Nice :) json-lib for the same JSON will throw OOM :P

I think we (Struts) will switch to this implementation, thank you for all your answers and
keep up the good work!


Cheers
Lukasz

On 2017-11-13 15:48, James Bognar <jamesbognar@apache.org> wrote: 
> That fails in ~130ms with the following exception...
> 
> org.apache.juneau.parser.ParseException: Parse exception occurred at
> {currentClass:'Object',line:1,column:61}.  Remainder after parse: ':'.
> at
> org.apache.juneau.json.JsonParserSession.validateEnd(JsonParserSession.java:744)
> at
> org.apache.juneau.json.JsonParserSession.doParse(JsonParserSession.java:88)
> at org.apache.juneau.parser.ParserSession.parseInner(ParserSession.java:509)
> at org.apache.juneau.parser.ParserSession.parse(ParserSession.java:465)
> at org.apache.juneau.parser.Parser.parse(Parser.java:423)
> at org.apache.juneau.json.Temp.main(Temp.java:26)
> 
> 
> If a StackOverflowError occurs, we catch it and rethrow a "Depth too deep.
> Stack overflow occurred." parse exception.  That doesn't happen in this
> case though since it's only 56-levels deep, and each level is only two
> stack entries deep.
> 
> If I do a repeated pattern like "{a:" x 2500, it causes a
> StackOverflowError in about 160ms.
> 
> It would be possible to add a max-depth setting just like what's available
> on the Serializer side.  However, I don't think depth is a concern.  We're
> not consuming memory on each recursion, so stack-overflows should not cause
> system instability.  My larger concern would be OutOfMemoryErrors caused by
> parsing a very large string or many medium sized ones.
> 
> 
> 
> On Mon, Nov 13, 2017 at 8:36 AM, Lukasz Lenart <lukaszlenart@apache.org>
> wrote:
> 
> > On 2017-11-10 18:47, James Bognar <jamesbognar@gmail.com> wrote:
> > > However, we don't have any limiters in place to prevent you from, for
> > > example, creating an infinitely long String field (other than the
> > built-in
> > > limitations on the StringBuilder class itself which is limited by an
> > int).
> > >
> > > I'm thinking it can be solved at the REST servlet interface with a
> > > BoundedReader (
> > > https://commons.apache.org/proper/commons-io/javadocs/
> > api-2.5/org/apache/commons/io/input/BoundedReader.html).
> > > The parsers themselves wouldn't need to be changed.
> > >
> > > Thoughts anyone?  What would be an appropriate default size limit on the
> > > input?  100MB?
> >
> > I'm not sure if this will help, try to parse this string:
> >
> > {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{}:1}
> > :1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}
> > :1}:1}:1}:1}:1}:1}}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:
> > 1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}
> >
> > Regards
> > Lukasz
> >
> 

Mime
View raw message