cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Possible security problem with flowscript
Date Fri, 15 Oct 2004 12:10:24 GMT
Carsten Ziegeler wrote:

>Today we came across a possible security problem when you use flow
>script. We tested the following example with and the
>current 2.1.x branch. Here is a simple example:
>We have two areas in our web application, one is available for every
>user and one area is only accessible for authenticated users.
>We create two sub sitemaps - one for each area. Both are using
>flow with different scripts. The second sitemap is protected
>by using the authentication framework (how the authentication
>is done is actually not important).
>In each sitemap we have a matcher for the continuation id:
>Sitemap for global area:
> - mounted at /global
> - flowscript global.js
> - matcher for continuation id
>   <map:match pattern="continue.*">
>       <map:call continuation="{1}"/>
>   </map:match>
>Sitemap for protected area:
> - mounted at /protected
> - flowscript protected.js
> - matcher for continuation id
>   <map:match pattern="*.cont">
>       <map:call continuation="{1}"/>
>   </map:match>
>Now, if someone is able to pick up a valid continuation id for the protected
>area, it is possible to continue the flow script in "protected.js" by
>calling: "/global/continue.CONT_ID".
>Which means there isn't any further check, if the continuation id belongs
>to the sitemap or to the used javascripts in that sitemap.
>And flow is able to continue the script without any problems.
>So it seems that it would be good if we would have some further checks.
>I think, it would be good if flow would check if the continuation id
>belongs to the sitemap where the map:call is performed. Currently the
>ids are global and not on a per sitemap level.
>Or we store the continuations in the session. Or?

This has already been identified by Leszek Gawron. Although this is an 
issue, it can only be exploited by hijacking a continuation ID which, if 
done, also means the ability to hijack the session ID and therefore the 
associated authorizations.

The solution for this is the continuation-per-session manager, where a 
continuation ID only exists within a given session.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message