You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Greg Wilkins <gr...@mortbay.com> on 2000/11/30 23:21:29 UTC

Web application security problem on windows

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<gr...@mortbay.com>          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

Re: Web application security problem on windows

Posted by se...@eng.sun.com.
Thank you for your feedback on the Servlet API. Your feedback will be
read by an engineer on the Java Servlet API Team and given serious
consideration. We will contact you directly if we have further
questions about your feedback.

----------------------------------------------------------------------

We do not perform sales or technical support from this address.  This
is worth repeating: you will not receive any additional mail, unless
we have questions on your feedback. Please contact one of our other
support channels (below) if you require support.

To place a bug report directly into our database, you may enter your
bug here: http://java.sun.com/cgi-bin/bugreport.cgi

For licensing, sales and schedule information, please contact
1-888-THEJAVA. If outside the US, please dial 1-(512)434-1591

----------------------------------------------------------------------

For more discussion of the servlet API please consider joining the
servlet-interest mailing list.

You may subscribe to the mailing list by sending an email to:

LISTSERV@JAVASOFT.COM

with the _body_ of the message containing the line

SUBSCRIBE SERVLET-INTEREST Full-Name-Here

where Full-Name-Here is your name.

Discussions of programming Java Servlets, and server side Java
programming in general, are carried out on the Usenet newsgroup
comp.lang.java.programmer.

----------------------------------------------------------------------

Thank you for your time and input.

The Servlet API Team