Re: [jetty-dev] Proposal for handling of overlapped contexts

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Michael,

note that there are legitimate reasons for overlapping context paths.
Virtual hosts and named connectors are both reasons that a context
with a matching context path may not handle a request and allow it to
fall through to another context.

So the first challenge is detecting an overlap without false
positives.  But checking virtual paths should get 99.9% of cases.

The we need to decide what to do in the case of an overlap:
 + Should we stop the old, then deploy the new?  But that could lose
some requests?
 + Should we start the new then stop the old? But that would mean we
can't easily migrate sessions
 + Should we provide some session migration assistance?

Whatever we decide,  I think this is an issue to be dealt with by the deployers.
So starting with a binding that detects overlap and warns about it
would be a start.   We can then think about how easy (or hard) it
would to provide additional bindings to implement various policies.


cheers

https://bugs.eclipse.org/bugs/show_bug.cgi?id=338872

On 16 March 2011 05:42, Michael Gorovoy <mgorovoy@xxxxxxxxxxx> wrote:
> Bug 338872 has been created to address the situation where two contexts
> contain overlapping context paths. This issue could potentially have
> security repercussions as a malicious app could potentially overlap a
> context path inside a legitimate app. There are several potential ways to
> resolve this issue, that are listed below.
>
> Enhance the StandardDeployer binding in DeploymentManager infrastructure to
> (optionally) check a context path of each application that is being deployed
> against context paths handled by applications that had already been
> deployed. If an overlapping context path has been found, it will cause the
> binding to fail, and the offending application would not reach Deployed
> state. This approach will work only for web applications that are deployed
> via DeploymentManager. It will require special handling for the application
> that is deployed at root context path. It will also require keeping the
> reference to the contexts that have already been checked. It should be
> possible to implement this by creating back-door access to the
> DeploymentManager app queue.
> Implement the validation of context paths as outlined above inside the
> Server class, and (optionally) execute it then the server is being started.
> This will have an advantage of being able to validate all context paths,
> rather when just the ones defined for web applications that are deployed
> through DeploymentManager. This will require a mechanism to be developed to
> validate contexts that are deployed dynamically after the server has been
> started.
>
> In any of the above scenarios, it would be necessary to develop a mechanism
> to determine whether an overlap is legitimate (e.g. context /foo overlapping
> the root context where root context doesn't have any handler for context
> path /foo). This will require developing a facility in ScopedHandler
> sub-classes that will allow traversing the chain of handlers and determining
> whether this chain has a handler that handles the specific context path.
> -Michael
> Michael Gorovoy | mgorovoy@xxxxxxxxxxx | http://www.intalio.com |
>