struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <musa...@gmail.com>
Subject Re: ParameterFilterInterceptor security issue
Date Tue, 12 Aug 2008 13:49:26 GMT
s/Memeber/Member/g

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
> rename StaticMemeberAccess to SecurityMemeberAccess, and in there not
> only block static member access, but also fields that can be
> configured using regular expressions. The params interceptor would
> 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> wrote:
>>
>> Am Di, 12.08.2008, 14:20, schrieb Jeromy Evans:
>>>
>>> This relates to Musachy's recent proposal to remove OGNL entirely 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 we
>> would decide to do so this won't be trivial and might have many side
>> effects.
>>
>>> If I've understood correctly, currently there is no way to filter the
>>> parameter names, using regex or otherwise, other than to verify them use
>>> a whitelist of valid names.
>>>
>>
>> You can blacklist parameter names in the ParameterInterceptor ref,
>> including the possibility to define RegExp patterns. The latter one is not
>> possible for the ParameterFilterInterceptor right now, which I 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 they
>>>> shouldn't be binding on.
>>>>
>>>> Say you have a User object, you do not want people to be able to bind on
>>>> the
>>>> isAdmin property.
>>>>
>>>> Various people remommended using the ParameterFilterInterceptor for this
>>>> but
>>>> it seems to be flatout broken
>>>>
>>>> When you configure an action like this
>>>>
>>>> <action name="test" class="com.webapp.action.TestAction">
>>>>     <interceptor-ref name="param-namevalue-filter">
>>>>        <param name="blocked">name</param>
>>>>     </interceptor-ref>
>>>>     <interceptor-ref name="params"/>
>>>> </action>
>>>>
>>>> then this wont work :
>>>>
>>>> /test.action?name=myname
>>>>
>>>> but this does :
>>>>
>>>> /test.action?(name)=jelmer
>>>>
>>>> and so does this
>>>>
>>>> /test.action?((name))=jelmer
>>>>
>>>> And so on, infact it is impossible to block any parameter effectively
>>>> with
>>>> the ParameterFilterInterceptor.
>>>>
>>>>
>>>> Btw. I am aware that there is also the excludeParams method on the
>>>> ParametersInterceptor that accepts a regexp, so theoretically you could
>>>> use
>>>> this to block parameters effectively but it would be extremely hard to
>>>> write
>>>> a correct regexp for it. Also I havent found a way to configure both
>>>> params
>>>> interceptors in a paramsPrepareParamsStack. This will only configure the
>>>> first params interceptor in the stack
>>>>
>>>> <interceptor-ref name="clientCrudStack">
>>>>    <param name="params.excludeParams">some pattern</param>
>>>> </interceptor-ref>
>>>>
>>>> Struts really seems to be lacking in this area.
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>



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

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


Mime
View raw message