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 (athena.apache.org: domain of Brian.Relph@cerner.com
 designates 159.140.213.229 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ParameterFilterInterceptor security issue
Date: Tue, 12 Aug 2008 09:22:10 -0500
Message-ID: <019EB22ED464A146A26211222DD06E17018099EC@EMAIL02.cerner.net>
In-Reply-To: <d8bdeb6f0808120652w1b8aae5fla6c924c250ccc10@mail.gmail.com>
Thread-Topic: ParameterFilterInterceptor security issue
Thread-Index: Acj8gsrmh64vKRt1SDOY1qmSyH5haQAAmgdA
References: <f60d4ed80808120224p507f492ne06e2afb8c9f70f4@mail.gmail.com>
 <48A1800A.3000104@blueskyminds.com.au>
 <39687.80.87.162.65.1218546847.squirrel@webmail.nrgie.net>
 <d8bdeb6f0808120648o25ea4c01k5b92b1a6ce9a98e7@mail.gmail.com>
 <d8bdeb6f0808120652w1b8aae5fla6c924c250ccc10@mail.gmail.com>
From: "Relph,Brian" <Brian.Relph@Cerner.com>
To: "Struts Developers List" <dev@struts.apache.org>

=20
I wrote an annotation based parameters interceptor that extends the current=
 parameters interceptor while allowing you to configure the default "accept=
" policy for an actions properties, as well as a per-property annotation th=
at can override the action's policy.  This lets you use the same intercepto=
r / interceptor stack for all actions, and configure each individually to a=
ccept or reject parameters.  I would still like to add some regex support t=
o the action annotation.  Would this interest you?

Brian Relph

-----Original Message-----
From: Musachy Barroso [mailto:musachy@gmail.com]=20
Sent: Tuesday, August 12, 2008 8:53 AM
To: Struts Developers List
Subject: Re: ParameterFilterInterceptor security issue

I forgot to say, that this would prevent all the OGNL expression tricks, be=
cause the property name that is passed to MemberAccess to be checked, is th=
e actual property name, and not an expression.

musachy

On Tue, Aug 12, 2008 at 9:48 AM, Musachy Barroso <musachy@gmail.com> wrote:
> It seems to me like there is an elegant solution to this. We can=20
> rename StaticMemeberAccess to SecurityMemeberAccess, and in there not=20
> only block static member access, but also fields that can be=20
> configured using regular expressions. The params interceptor would=20
> just set these fields before binding the params.
>
> //OGNL parameter binding just went to #2 in my "must kill" list :)
>
> musachy
>
> On Tue, Aug 12, 2008 at 9:14 AM, Rene Gielen <gielen@it-neering.net> wrot=
e:
>>
>> Am Di, 12.08.2008, 14:20, schrieb Jeromy Evans:
>>>
>>> This relates to Musachy's recent proposal to remove OGNL entirely=20
>>> from the parameter-setting process.  Which I think is a very good idea.
>>>
>>
>> Indeed removing OGNL for parameters would fix this issue, but even if=20
>> we would decide to do so this won't be trivial and might have many=20
>> side effects.
>>
>>> If I've understood correctly, currently there is no way to filter=20
>>> the parameter names, using regex or otherwise, other than to verify=20
>>> them use a whitelist of valid names.
>>>
>>
>> You can blacklist parameter names in the ParameterInterceptor ref,=20
>> including the possibility to define RegExp patterns. The latter one=20
>> is not possible for the ParameterFilterInterceptor right now, which I=20
>> think is a feature we should add.
>>
>> Jelmer, would you mind creating an Jira issue for that?
>> https://issues.apache.org/struts/
>>
>> - Rene
>>
>>> jelmer wrote:
>>>> Hi all,
>>>>
>>>> I was looking into an easy way to prevent people binding on fields=20
>>>> they shouldn't be binding on.
>>>>
>>>> Say you have a User object, you do not want people to be able to=20
>>>> bind on the isAdmin property.
>>>>
>>>> Various people remommended using the ParameterFilterInterceptor for=20
>>>> this but it seems to be flatout broken
>>>>
>>>> When you configure an action like this
>>>>
>>>> <action name=3D"test" class=3D"com.webapp.action.TestAction">
>>>>     <interceptor-ref name=3D"param-namevalue-filter">
>>>>        <param name=3D"blocked">name</param>
>>>>     </interceptor-ref>
>>>>     <interceptor-ref name=3D"params"/> </action>
>>>>
>>>> then this wont work :
>>>>
>>>> /test.action?name=3Dmyname
>>>>
>>>> but this does :
>>>>
>>>> /test.action?(name)=3Djelmer
>>>>
>>>> and so does this
>>>>
>>>> /test.action?((name))=3Djelmer
>>>>
>>>> And so on, infact it is impossible to block any parameter=20
>>>> effectively with the ParameterFilterInterceptor.
>>>>
>>>>
>>>> Btw. I am aware that there is also the excludeParams method on the=20
>>>> ParametersInterceptor that accepts a regexp, so theoretically you=20
>>>> could use this to block parameters effectively but it would be=20
>>>> extremely hard to write a correct regexp for it. Also I havent=20
>>>> found a way to configure both params interceptors in a=20
>>>> paramsPrepareParamsStack. This will only configure the first params=20
>>>> interceptor in the stack
>>>>
>>>> <interceptor-ref name=3D"clientCrudStack">
>>>>    <param name=3D"params.excludeParams">some pattern</param>=20
>>>> </interceptor-ref>
>>>>
>>>> Struts really seems to be lacking in this area.
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For=20
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>


--
"Hey you! Would you help me to carry the stone?" Pink Floyd

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

----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from C=
erner Corporation and are intended only for the addressee. The information =
contained in this message is confidential and may constitute inside or non-=
public information under international, federal, or state securities laws. =
Unauthorized forwarding, printing, copying, distribution, or use of such in=
formation is strictly prohibited and may be unlawful. If you are not the ad=
dressee, please promptly delete this message and notify the sender of the d=
elivery error by e-mail or you may call Cerner's corporate offices in Kansa=
s City, Missouri, U.S.A at (+1) (816)221-1024.

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