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
