[ANNOUNCEMENT] Tomcat 3.2 Beta 7

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Hear ye!  Hear ye!  At long last, an updated "beta 7" release of Tomcat
3.2 is available for download, at:

    http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-7

Relative to "beta 6", a very large number of bug fixes have been applied
-- thanks to all who have been reporting them via BugRat and the mailing
lists.

Please download this release and give it a try in your environment.  If
no more critical bugs are found, this will become the basis for the
final release of Tomcat 3.2, in approximately one week.

Craig McClanahan

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

[Christian Wenz <ch...@stud.tu-muenchen.de>]

Hi,

"Craig R. McClanahan" wrote:

> Please download this release and give it a try in your environment.  If
> no more critical bugs are found, this will become the basis for the
> final release of Tomcat 3.2, in approximately one week.

ah, nice to know. Thanks for the info, looking forward to it!

Christian

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

["Craig R. McClanahan" <Cr...@eng.sun.com>]

cmanolache@yahoo.com 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

Security constraints for forward()/include() [Was: Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7]

[Hans Bergsten <ha...@gefionsoftware.com>]

Hans Bergsten wrote:
> 
> cmanolache@yahoo.com 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.
> > > [...]
> > > This does *not* seem to be the case. I have an example that uses the RD to
> > > forward() to JSP pages that are protected from direct access using BASIC
> > > authentication. It works exactly as it should: forward() invokes them but
> > > a direct access prompts for username/password. You may want to look at
> >
> > If this is the case probably something changed in the implementation, and
> > we should at least find out if the danger is real and document that.
> 
> I'll try to take a look at the code today or tomorrow to see what's going
> on. But the way it works now (at least in my test case) is the way it
> should work according to 2.3, so I agree that we should leave it as it is
> and just document how it works (if it's different than 2.3 after all and
> if those differences poses a security threat).

I've looked at the code to try to figure out why it doesn't work as Costin
intended, and instead works as specified in 2.3, but I'm afraid there are
just too many interceptors involved and too little time for me to dig deeper.

Anyway, from tracing it's clear that the AccessInterceptor gets invoked
even for a forward() and it calls req.setRequiredRoles( roles ) so that
the "roles will be checked by a different interceptor". I assume this is
the SimpleRealm interceptor, but it's never invoked for a forward(). Maybe
this is because ContextManager.processRequest() (called by the RD) never 
calls the authorize() method in the interceptions, only contextMap() and 
requestMap().

An in all, I'm happy with the current behavior and I suggest that 
"6.8 Container Managed Security Constraints" is removed from the README
in the final release build. It would nice, however, if someone else can
verify this as well, since I didn't find out exactly why it works as it
should ;-)

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

[cm...@yahoo.com]

> > 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.
> > 
> > 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.
> 
> 2.3 assumes that security is handled at the web app level, by restricting
> access to RDs for another app. This is also in the 2.1 spec. I'm not sure
> I understand why you think that's "not always possible or a good idea."

I think 2.2 doesn't assume that ( and at the time the implementation was
written, there was no 2.3 ). Plus the previous code seemed to work that
way. 

I said it's not always possible because Tomcat3.2 doesn't implement any
restrictions on ServletContext.getContext() - it's on the todo list, but
we need a way to express what apps can access other apps, and that's not
defined ( AFAIK ). 

Also, most servers ( Apache, etc ) seem to do a full processRequest for
internal redirects - that include authentication/authorization - and again
we'll make even harder to integrate web servers with the servlet api. 

Anyway - it's not a big deal, in 3.3 we'll have to implement restrictions
on ServletContext.getContext() and that'll resolve the problem, and 3.2
doesn't claim to be able to run multiple security domains ( it can run
untrusted apps, but can't isolate one app from another - the 3.2 core is
still not there ). 

Costin

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

[Hans Bergsten <ha...@gefionsoftware.com>]

cmanolache@yahoo.com 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.
> 
> 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.

2.3 assumes that security is handled at the web app level, by restricting
access to RDs for another app. This is also in the 2.1 spec. I'm not sure
I understand why you think that's "not always possible or a good idea."

> > This does *not* seem to be the case. I have an example that uses the RD to
> > forward() to JSP pages that are protected from direct access using BASIC
> > authentication. It works exactly as it should: forward() invokes them but
> > a direct access prompts for username/password. You may want to look at
> 
> If this is the case probably something changed in the implementation, and
> we should at least find out if the danger is real and document that.

I'll try to take a look at the code today or tomorrow to see what's going
on. But the way it works now (at least in my test case) is the way it
should work according to 2.3, so I agree that we should leave it as it is
and just document how it works (if it's different than 2.3 after all and
if those differences poses a security threat).

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

[cm...@yahoo.com]

>   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.

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.
 
 
> This does *not* seem to be the case. I have an example that uses the RD to
> forward() to JSP pages that are protected from direct access using BASIC
> authentication. It works exactly as it should: forward() invokes them but 
> a direct access prompts for username/password. You may want to look at

If this is the case probably something changed in the implementation, and
we should at least find out if the danger is real and document that.

Costin

Re: [ANNOUNCEMENT] Tomcat 3.2 Beta 7

[Hans Bergsten <ha...@gefionsoftware.com>]

"Craig R. McClanahan" wrote:
> 
> Hear ye!  Hear ye!  At long last, an updated "beta 7" release of Tomcat
> 3.2 is available for download, at:
> 
>     http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-7
> [...]

Thanks a bunch Craig, and everyone else who helped out getting all the 
remaining bugs squashed.

I have tested the stand-alone config with a lot of JSP examples (heavy on
custom actions and beans) on Windows NT 4.0 with JDK 1.3, and everything
works great! One thing though: the README file says in "Known Bugs"

  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.

This does *not* seem to be the case. I have an example that uses the RD to
forward() to JSP pages that are protected from direct access using BASIC
authentication. It works exactly as it should: forward() invokes them but 
a direct access prompts for username/password. You may want to look at
this again, and either clarify (if it's a special case that doesn't work)
or remove this item from the list.

I'll try to get a chance to run through some examples on Windows 98 and 
Linux as well tomorrow, just to make sure the startup scripts are okay and 
that there are no obvious platform dependent problems.

Thanks again,
Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com