tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: MVC problem
Date Fri, 01 Dec 2000 00:32:14 GMT
"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 URL
> 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 things
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 require
> our developers to use a servlet subclass, but this would be non-MVC-like. Is
> 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 in
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, because
none of the JSP pages would be directly accessible.

>
> thanks!
> david
>

Craig


>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Thursday, November 30, 2000 12:43 PM
> To: tomcat-dev@jakarta.apache.org
> Cc: 'mike.labudde@irista.com'
> 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 JSP/servlet
> > 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 paragraph).
>
> 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 configuration
> 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
> :-)


Mime
View raw message