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
