Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <436d9a250707160638j247768f4pbc1cfd8def52a256@mail.gmail.com>
References: <1c661f2f0707152355g2efd8913h5448d5a23df25cb2@mail.gmail.com>
 <1c661f2f0707160431m28a87ab1l1c7b1046c4bb3a87@mail.gmail.com>
 <93baab320707160440u17ace78awac6c4dbbd1e345e2@mail.gmail.com>
 <1c661f2f0707160449m42ce01afnd281406cb5a6e284@mail.gmail.com>
 <1184588807.22613.1200363959@webmail.messagingengine.com>
 <436d9a250707160536m472afdfbj4e206156a26e435@mail.gmail.com>
 <d8bdeb6f0707160632o601d0efbq414914c44f39b7cb@mail.gmail.com>
 <436d9a250707160638j247768f4pbc1cfd8def52a256@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7D6CA52B-639D-4BA2-9726-0FE0FDAC286B@andreavettori.com>
Content-Transfer-Encoding: 7bit
From: "Ing. Andrea Vettori" <mail@andreavettori.com>
Subject: Re: Preventing OGNL evaluations of user input (was Re: Struts 2
 performance)
Date: Mon, 16 Jul 2007 16:02:08 +0200
To: "Struts Developers List" <dev@struts.apache.org>

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