struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ing. Andrea Vettori" <m...@andreavettori.com>
Subject Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Date Mon, 16 Jul 2007 14:56:11 GMT
At a first look (but haven't tried because I don't have a compiler  
here :) that kind of expression is correctly evaluated by Don patch.

The only thing is that evaluation order is changed.

The actual version evaluates always left to right in only one pass.  
So it is like depth-first recursion.

Don patch seems to evaluate on many runs from left to right and  
evaluating all expression at the same level first (don't remember the  
name for this type of recursion :)


Il giorno 16/lug/07, alle ore 16:21, Musachy Barroso ha scritto:

> I do use it
>
> musachy
>
> On 7/16/07, Ing. Andrea Vettori <mail@andreavettori.com> wrote:
>>
>> What about expression like "%{foo} %{bar}" that work with the current
>> version but don't work using the loopCounter patch ?
>>
>> I don't think we need them but who knows...
>>
>>
>> Il giorno 16/lug/07, alle ore 15:38, Don Brown ha scritto:
>>
>> > From my tests, recursion is never really used and is just a
>> > byproduct of how
>> > the text parsing algorithm works.  I improved the algorithm to be
>> > able to
>> > detect and selectively enable recursion, although it is off by
>> > default.
>> > Having done that, all XWork and Struts 2 tests still passed, so I'm
>> > fairly
>> > confident most, if not all, WW/S2 applications should be ok.
>> >
>> > Don
>> >
>> > On 7/16/07, Musachy Barroso <musachy@gmail.com> wrote:
>> >>
>> >> I wouldn't agree that's a good solution, as it will be more
>> >> difficult for
>> >> users to understand, they will have to remember the enable/disable
>> >> the
>> >> recursion with serious problems if they don't, and questions will
>> >> be asked
>> >> by the thousands on the mailing list :). On top of that it will  
>> break
>> >> backward compatibility big time.
>> >>
>> >> The only drawback of preventing the evaluation of parameters is
>> >> that if
>> >> someone is trying to pass a parameter in the form %{...}, it won't
>> >> work,
>> >> which most likely nobody is doing, and if they have to, they could
>> >> escape
>> >> it
>> >> to %\{...\} or something else.
>> >>
>> >> musachy
>> >>
>> >> On 7/16/07, Don Brown <mrdon@twdata.org> wrote:
>> >> >
>> >> > I think the real solution is in fixing the recursive processing
>> >> of text.
>> >> > I'm working on a patch that will ensure the 'value' attribute  
>> isn't
>> >> > processed recursively, thereby, resolving our issue.  The
>> >> question then
>> >> is
>> >> > to turn recursive processing on by default or not.  If not and
>> >> we make a
>> >> > special case for the 'value' attribute, it could still be
>> >> possible for
>> >> the
>> >> > user to shoot themselves in the foot by creating a localisation
>> >> message
>> >> > such
>> >> > as:
>> >> >
>> >> > The name needs at least %{minSize} characters
>> >> >
>> >> > Then, the attacker just needs to submit a form with a field  
>> like:
>> >> >
>> >> > <input type="hidden" name="minSize" value="%
>> >> {@java.lang.System@exit(0)}"
>> >> > />
>> >> >
>> >> > This happens because the form parameters are on the top of the
>> >> stack
>> >> > usually.
>> >> >
>> >> > Therefore, the safest solution is to turn recursive processing
>> >> off by
>> >> > default and selectively allow a user to allow recursion through
>> >> an extra
>> >> > tag
>> >> > attribute or similar means.  However, that will definitely break
>> >> existing
>> >> > apps, where only turning recursion off for the 'value' attribute
>> >> has a
>> >> > much
>> >> > smaller chance of breaking apps.
>> >> >
>> >> > Don
>> >> >
>> >> > On 7/16/07, Martin Gilday <martin.lists@imap.cc> wrote:
>> >> > >
>> >> > > As has been said the current fix is not ideal.  The changes
>> >> that have
>> >> > > been made to params interceptor mean that the functionality in
>> >> > > ParamsInterceptor and ParamFilterInterceptor are now very
>> >> similar,
>> >> > > except one supports regex.  Would it be worthwile trying to
>> >> combine
>> >> > > these now that it is apparent they are crucial to security?
>> >> With this
>> >> > > fix there is the danger now that as soon as anyone adds in
>> >> there own
>> >> > > "excludePattern" they can remove the default which is
>> >> preventing the
>> >> > > ognl hack, without realising the problem they are creating.
>> >> > >
>> >> > >
>> >> > > ----- Original message -----
>> >> > > From: "Don Brown" <donald.brown@gmail.com>
>> >> > > To: "Struts Developers List" <dev@struts.apache.org>
>> >> > > Date: Mon, 16 Jul 2007 21:49:15 +1000
>> >> > > Subject: Re: Preventing OGNL evaluations of user input (was
>> >> Re: Struts
>> >> 2
>> >> > > performance)
>> >> > >
>> >> > > Continuing in dev@ ...
>> >> > >
>> >> > > On 7/16/07, Aram Mkhitaryan <aram.mkhitaryan@googlemail.com>
>> >> wrote:
>> >> > > > Don, could you please send the subject to continue the
>> >> discussion
>> >> in?
>> >> > > > Should we use dev@struts.apache.org?
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Aram
>> >> > > > ________________________________
>> >> > > > Aram Mkhitaryan
>> >> > > >
>> >> > > > 52, 25 Lvovyan, Yerevan 375000, Armenia
>> >> > > >
>> >> > > > Mobile: +374 91 518456
>> >> > > > E-mail: aram.mkhitaryan@googlemail.com
>> >> > > >
>> >> > >
>> >> > >
>> >>  
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> > > For additional commands, e-mail: dev-help@struts.apache.org
>> >> > >
>> >> > >
>> >> > >
>> >>  
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> > > For additional commands, e-mail: dev-help@struts.apache.org
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >>
>>
>> --
>> Ing. Andrea Vettori
>> Consulente per l'Information Technology
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> -- 
> "Hey you! Would you help me to carry the stone?" Pink Floyd

--
Ing. Andrea Vettori
Consulente per l'Information Technology



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message