tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7
Date Fri, 17 Nov 2000 23:54:22 GMT wrote:

> >   6.8 Container Managed Security Constraints
> >   Due to the way that Tomcat 3.2 is implemented, container managed security
> >   constraints are imposed both on the original request URI *and* on subrequests
> >   initiated to handle RequestDispatcher.forward() or RequestDispatcher.include()
> >   calls.
> Since I did part of the implementation, my intention was to check the
> security constraints on forward and include.
> The reason - it's a huge security hole to not check them ( IMHO ) - a site
> running multiple webapps ( with different security constraints ) may be
> compromised if the constraints of the original requests are propagated on
> forward. ( you can get a request dispatcher for a different webapp - and
> then call include for a "secure" page ). Disabling access to other webapps
> is not allways possible or a good idea.

It is certainly allowed to disable access to other webapps.  The Javadocs for
ServletContext.getContext() say:

    "In a security conscious environment the servlet
    container may return null for a given URL."

In Tomcat 4.0, you enable this protection by saying crossContext="false" on your
<Context> element.  I'm going to add a similar option to 3.2.

> Of course, in 2.3 that seems to be required by the spec - I just hope I'm
> wrong and there is a way to avoid the security hole.

If you don't want your JSP pages accessed directly (but only thrown a controller
servlet in an MVC architecture, for example), the prescribed mechanism in 2.3 is to
place them under a security constraint that has an <auth-constraint> element with no
nested <role-name> elements.  The container interprets this as "no direct access from
clients", so the only access to such pages is through a RequestDispatcher (in a
servlet) or <jsp:include> or <jsp:forward> (in a JSP page).

> Costin

Craig McClanahan

View raw message