Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4171ACDE.3020903@curalia.se>
Date: Sun, 17 Oct 2004 01:21:02 +0200
From: Niklas Eklund <niklas@curalia.se>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Possible security problem with flowscript
References: <200410151346.i9FDkAF21833@s2.nedstars.nl>
    <006f01c4b2c1$89a460a0$0701a8c0@rbe> <416FF4B5.6030203@curalia.se>
    <416FF90B.2000502@mobilebox.pl>
 <33123.80.219.8.172.1097965303.squirrel@80.219.8.172>
In-Reply-To: <33123.80.219.8.172.1097965303.squirrel@80.219.8.172>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Antonio Gallardo wrote:
> Leszek Gawron dijo:
> 
>>Niklas Eklund wrote:
>>
>>>Rob Berens wrote:
>>>
>>>
>>>>Carsten Ziegeler wrote:
>>>>
>>>>
>>>>>Hmm, I might be wrong, but does this really protect you?
>>>>>If you have a flow that is usable by not authenticated users,
>>>>>you run into the same problem I think.
>>>>>
>>>>
>>>>I see, you are right. A unauthorized user can get access to the
>>>>continuation
>>>>by adding the continuation parameter to another request he is
>>>>authorized
>>>>for.
>>>
>>>
>>>I have solved a similar problem in an application by using a wrapped
>>>sendPage() like:
>>>
>>>function w_sendPage(x, y, z) {
>>>  var currentUser = getCurrUser(); // userPrincipal/remoteUser/whatever
>>>  sendPage(x, y, z);
>>>  if (currentUser != getCurrUser()) {
>>>     throw "Bad boy!";
>>>  }
>>>}
>>
>>It's nice but does not work for cforms.
> 
> 
> I think you mean, when you are inside the cforms (while the user do the
> second cform request to validate de user data.... please see this pieces
> of code. We use something very similar in flow:
> 
> function createform(form) {
>     if (authorise("resourceName")) {
>         form.showForm("my-form-display");
>     }
> }
> 
> On the sitemap we use to put everything inside an internal pipeline and
> just one "external" pipeline:
> 
> <map:pipeline>
>   <map:match pattern="*">
>     <map:call function="protect">
>       <map:parameter name="handler" value="authhandler"/>
>       <map:parameter name="protected-internal" value="{1}"/>
>       <map:parameter name="failure-redirect" value="/entrada?resource={1}"/>
>     </map:call>
>   </map:match>
> </map:pipeline>
> 
> Note that what everthing that is coming in is checked.
> 
> 
> Of course that if the session is also hijacket it will not work too. But I
> think this is another story..... ;-)
> 
> ...Maybe, we can add a user validation handler inside the cforms. But this
> solution (at first sight) is not too "clean" to my taste. Because we need
> to write validation handler for each form => more boring code :( I don't
> like that at all!
> 
> ...This works for us. But I think we need to test that in the Carsten
> case. I think it could past the test.
> 

Yes, but why not apply it at a lower level so that cforms users won't 
even know about it (apology for not having used cforms myself yet and 
possibly missing finer points...)? Something similar to the solution 
I've used, but smarter and covering all cases, would be fairly useful, 
right? The real problem to solve at a lower level is what kind of 
authentication is the server using, which is  possible to solve by 
adding the similar hooks to what Vadim proposed (with default 
implementations), which let the developer choose more or less... However 
retrieving userPrincipal is at least staying within the servlet spec afaik?

IMHO a hijacked continuation should be caught at the lowest level 
possible relieving the application developer from using such logic...

Regards,
  Niklas