tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aiken, David" <>
Subject RE: MVC problem
Date Fri, 01 Dec 2000 20:22:46 GMT
Thanks for the feedback.. we'll digest this for a bit to determine a
suitable strategy. Any idea when tomcat 4.0 will be stable?


-----Original Message-----
From: Craig R. McClanahan []
Sent: Thursday, November 30, 2000 6:32 PM
Cc: ''
Subject: Re: MVC problem

"Aiken, David" wrote:

> "No file contained in the WEB-INF directory may be served directly to a
> client."
> That seems pretty clear.. we tried directly accessing JSP pages using a
> of the form http://localhost:8080/examples/WEB-INF/index.jsp and it
> delivered the page using tomcat 3.2 on a W2K system - is it necessary to
> configure something to enforce this restriction?

Yep (grrr ... happens in 3.2 final and 4.0 current code).

Both of these versions have traps to avoid serving static files from WEB-INF
(even if you try to circumvent it on non-case-sensitvie platforms with
like "/WeB-iNf/web.xml").  It never occurred to me that anyone would ever
put a
JSP page there :-(.

> We're also wondering about restricting access to servlets.. we could
> our developers to use a servlet subclass, but this would be non-MVC-like.
> there a way to govern access to them from a controller servlet?

One approach that will work in Tomcat 4.0 (because it was planned that way
the servlet 2.3 spec) is based on the following reasoning:

* Security constraints are imposed only on the original request URI,
  not when doing RequestDispatcher.include or RequestDispatcher.forward

* Therefore, we can prohibit direct access to servlets (or JSP pages) by
  protecting them with a security constraint that disallowed access.

* In 2.3, if you define a security contraint that has an <auth-constraint>
  element with no nested <role-name> elements, the container interprets
  this to mean that absolutely no direct access to the protected URIs
  is allowed via requests -- they can only be accessed indirectly via
  a RequestDispatcher.

* You can simulate this behavior in 2.2 by using a security constraint with
  a <role-name> to which no users have been assigned.

Doing this forces all requests to come through your controller servlet,
none of the JSP pages would be directly accessible.

> thanks!
> david


> -----Original Message-----
> From: Craig R. McClanahan []
> Sent: Thursday, November 30, 2000 12:43 PM
> To:
> Cc: ''
> Subject: Re: MVC problem
> "Aiken, David" wrote:
> > That sounds workable.. i looked for an archive of this newsgroup but
> didn't
> > have any luck - do you know where the relevant section in the
> > spec is?
> >
> Do you mean the restriction on serving things from WEB-INF directly to the
> client?
> Servlet 2.2 Spec, Section 9.4, p. 44 (last sentence of the first
> Servlet 2.3 Spec (Proposed FInal Draft), Section 9.4, p. 59 (last sentence
> of
> the second paragraph in this section).
> Basically, the prohibition means that the following sorts of URLs:
>     http://localhost:8080/myapp/WEB-INF/web.xml
> will return an error instead of exposing potentially sensitive
> information in your deployment descriptor.
> A servlet can still access things under WEB-INF -- for example, the JSP
> servlet
> needs to read web.xml when you use custom tags (to look for <taglib>
> elements),
> and it does this:
>     InputStream is =
>       getServletContext().getResourceAsStream("/WEB-INF/web.xml");
> You can do the same with other configuration files that contain sensitive
> stuff
> -- the WEB-INF directory is a good place to put them.
> >
> > thanks!
> > david
> >
> Craig
> PS:  Yes, I *have* almost memorized the specs over the last couple months
> :-)

View raw message