[EMAIL PROTECTED] 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
