Return-Path: 
 <dev-return-58430-apmail-struts-dev-archive=struts.apache.org@struts.apache.org>
Delivered-To: apmail-struts-dev-archive@www.apache.org
Received: (qmail 95796 invoked from network); 12 Aug 2008 09:58:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 12 Aug 2008 09:58:49 -0000
Received: (qmail 95715 invoked by uid 500); 12 Aug 2008 09:58:47 -0000
Delivered-To: apmail-struts-dev-archive@struts.apache.org
Received: (qmail 95679 invoked by uid 500); 12 Aug 2008 09:58:46 -0000
Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@struts.apache.org>
List-Help: <mailto:dev-help@struts.apache.org>
List-Post: <mailto:dev@struts.apache.org>
List-Id: "Struts Developers List" <dev.struts.apache.org>
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Delivered-To: mailing list dev@struts.apache.org
Received: (qmail 95668 invoked by uid 99); 12 Aug 2008 09:58:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2008 02:58:46 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [85.214.44.140] (HELO e.nrgie.net) (85.214.44.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2008 09:57:50 +0000
Received: from webmail.nrgie.net (localhost [127.0.0.1])
	by e.nrgie.net (Postfix) with ESMTP id F1635ACC03E
	for <dev@struts.apache.org>; Tue, 12 Aug 2008 11:58:11 +0200 (CEST)
Received: from 80.87.162.65
        (SquirrelMail authenticated user rene)
        by webmail.nrgie.net with HTTP;
        Tue, 12 Aug 2008 11:58:12 +0200 (CEST)
Message-ID: <49421.80.87.162.65.1218535092.squirrel@webmail.nrgie.net>
In-Reply-To: <f60d4ed80808120224p507f492ne06e2afb8c9f70f4@mail.gmail.com>
References: <f60d4ed80808120224p507f492ne06e2afb8c9f70f4@mail.gmail.com>
Date: Tue, 12 Aug 2008 11:58:12 +0200 (CEST)
Subject: Re: ParameterFilterInterceptor security issue
From: "Rene Gielen" <gielen@it-neering.net>
To: "Struts Developers List" <dev@struts.apache.org>
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Checked: Checked by ClamAV on apache.org

I would not go so far to consider this a security issue, I'd rather say
ParameterFilterInterceptor might not be feature complete.

I think it would be straightforward to also enable RegExp for
ParameterFilterInterceptor, to enhance it's usability in this case.

What exactly would be that hard when writing a RegExp for
ParametersInterceptor? If you know your "evil" parameter names, you could
quite safely use a somewhat greedy pattern like .*evilParamName.* IMO.

- Rene

Am Di, 12.08.2008, 11:24, schrieb jelmer:
> 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