Colin Sampaleanu wrote:
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: November 15, 2000 8:51 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: *.jsp "back door" issue
> >
> > Joel Schneider wrote:
> >
> > > Description of Problem:
> > >
> > > A typical Struts based web site might be configured to have requests
> > > matching the pattern"*.do" sent to the ActionServlet.
> > After a request is
> > > handled by its Action class, processing is typically
> > forwarded to a .jsp
> > > page.
> > >
> > > However, it's also possible for users to directly request a
> > .jsp page.
> > > When this happens, the JSP container (in my case, Orion)
> > will process the
> > > .jsp page without any involvement by the ActionServlet.
> > Some .jsp pages
> > > may yield unexpected results when called in this manner.
> > >
> >
> > Besides David Geary's suggestion, another approach is
> > supported by the servlet
> > API if you are using container-managed security for your
> > application. You can
> > define a security constraint that lists no roles as being
> > allowed, which the
> > servlet container will interpret as not allowing access to
> > anyone directly
> > from a request. You can forward to (or include) such a page
> > -- just not
> > request it directly.
> >
> > Note that this behavior was not clearly specified in the 2.2
> > servlet spec, so
> > your mileage might vary there -- but all 2.3 containers are
> > required to act
> > this way.
>
> Can you clarify this (I don't have the Servlet 2.3 specs around right now,
> but will look this up myself later if needed.
>
Sorry ... I was headed for an airplane and didn't have time to write out an
example. Consider the following security constraint:
<security-constraint>
<web-resource-collection>
<web-resource-name>All JSP Pages</web-resource-name>
<url-pattern>/pages/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- No roles listed here -->
</auth-constraint>
</security-constraint>
In a servlet 2.3 container (such as Tomcat 4.0), this is interpreted to mean
that there is no direct access at all to any URL like:
http://localhost:8080/myapp/pages/menu.jsp
but you are allowed to use a request dispatcher to access them. This is
because security constraints are to be checked only on the *original* URL, not
on the forward/include. Thus, if you want to ensure that a page is accessed
only via the controller servlet, you can give it a URL path within the "pages"
subdirectory, and the container will take care of this for you.
>
> I have actually noticed that Resin 1.2 and TomCat 3.2 differ in this
> respect. If you have declarative security set for your paths, and you come
> in from the browser, but servlet engines will redirect you to a login if
> needed, and check roles on access. If you then internally do a forward to
> another url, Resin will agian check roles, while TomCat will not. Are you
> saying that Resin is not compliant with the Servlet 2.3 specs, and TomCat
> is?
As I mentioned earlier, this behavior was not specified explicitly in servlet
2.2, so you cannot count in consistent behavior. (In fact, the person who
wrote this part of Tomcat 3.2 *intended* it to act the way Orion does -- it's
a bug that it doesn't :-).
If Resin 1.2 claims to implement servlet 2.2, they are OK (since it's not
specified). If they claim to implement servlet 2.3, they need to review the
following stuff in the Servlet 2.3 Proposed Final Draft spec, dated October
20, 2000, at <http://java.sun.com/products/servlet/download.html>:
Section 12.2, third paragraph:
The security model is declared in this way to apply to both
static content part of the web application and to Servlets
within the application that are requested by the client. The
security model does not intervene between a Servlet using
the RequestDispatcher to invoke a static resource or Servlet
and the static resource or servlet being requested by a
forward() or an include().
Craig
