Since version 2.2 the specification has been explicit that web containers
should not serve back anything that is in your WEB-INF/ archive entry in the
WAR as a result of a direct call from a client. The reason was to protect the
integrity of the web application. Some folks use the WEB-INF/ directory for
storing app specific configuration information which may be sensitive too.
They can of course retrieve this within a Servlet using the getResource() API
on the ServletContext.
I see you cross posted to the Tomcat team so they are aware of it - thanks -
I'm sure Craig has it under control.
- Danny
> Web applications running on Windows (or other systems with non case
> sensitive file systems) can have secure content accessed by
> using different case. The problem is a design problem for
> security-constraints and an implementation problem for WEB-INF
>
> For example I have been able to access /WeB-iNf/web.xml on several
> public servers running tomcat/catalina on NT. The current release
> of Jetty3 also is vulnerable and probably most other servlet
> containers.
>
> As URLs are case sensitive, the security constraints are bypassed
> by the different case request. However, once these requests are
> converted to real filenames or file URLs, the JVM is able to
> provide a file for them.
>
> The impact of this can be significant, as it allows unauthorized access
> to WEB-INF/web.xml. Furthermore any code in WEB-INF/classes or
> WEB-INF/lib may be accessed and decompiled and inspected for other
> vulnerabilities.
>
> Also vulnerable are any servlets written using getResource or
> getRealPath APIs that pass/use pathInfo. If these servlets are
> protected by a security constraint including alpha numeric
> characters, then they are vulnerable.
>
> For example, a security constraint of /secret/* will not
> protect a JSP like /secret/private.jsp. As a request to
> /SeCrEt/private.jsp will correctly bypass the security
> constraint, while the JspServlet at *.jsp will be able to find a
> matching jsp source file using getRealPath and/or getResource.
> Which will be compiled and a result returned. Note that
> both the security constraint and the JSP servlet are acting
> correctly for their given path specifications.
> NB. I have verified that jasper (3.1) is vulnerable to this attack.
>
> A general fix will be difficult to find, as many servlets use
> getRealPath and their own file handling. Furthermore, the
> real case of a file cannot be determined easily (getCanonicalPath
> does not return the actual file's case on at least one popular
> JVM (sun JDK1.2.2 on linux accessing a remote NT file system).
> Thus a general check for case matching cannot be made.
>
> I am currently of the opinion that design changes are needed in
> the security-constraint mechanism to at least allow case
> insensitive url-patterns to be used.
>
> A better solution would be to specify the behaviour of multiple
> security constraints, plus allow relaxing constraints.
> This may even be possible within the current web.dtd?
> If the most specific security constraint takes precedent (as it
> probably does), then a reasonable solution can be reached by
> placing a restrictive constraint on / and then defining less
> restrictive constraints on more specific paths. This may be
> a valid interpretation of the current specification, but if
> so, it needs to be clarified.
>
> Note that protection of the WEB-INF directory is separate
> to considerations of user defined security constraints, other
> than it probably shares a common implementation. WEB-INF should be
> protected from case base access regardless of any action taken on
> security constraints.
>
> A final point is that this may show that it may not have
> been a good idea to place WEB-INF and all it's content
> within the document root. Perhaps an alternate web application
> directory layout can be considered with a document root as
> a sibling or child rather than a parent of WEB-INF.
> eg. if WEB-INF/docroot exists, then it becomes the
> document root.
>
> regards
>
> PS. sorry if this has been raised before in these forums, but
> my searches could not find anything
>
> --
> Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)2074394045
> Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
> http://www.mortbay.com AU Phone: +61-(0)2 99772395
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
