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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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="[EMAIL PROTECTED]@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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]> wrote:
> > > Don, could you please send the subject to continue the discussion
in?
> > > Should we use [EMAIL PROTECTED]
> > >
> > > Thanks,
> > > Aram
> > > ________________________________
> > > Aram Mkhitaryan
> > >
> > > 52, 25 Lvovyan, Yerevan 375000, Armenia
> > >
> > > Mobile: +374 91 518456
> > > E-mail: [EMAIL PROTECTED]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
