tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petr Jiricka <petr.jiri...@netbeans.com>
Subject RE: Web application security problem on windows
Date Fri, 01 Dec 2000 13:05:01 GMT
Does not the following address this issue for Tomcat 3.2 ? (from
$TOMCAT_HOME/doc/readme)


6.7 URL's are now case sensitive on all operating systems

As of Tomcat 3.2, URL's are case sensitive for all operating systems,
including operating systems which have case insensitive file systems, such
as
Windows.  This represents a change from Tomcat 3.1, where URL's were case
insensitive on case insensitive OS's.  This was done for a number of
reasons,
security and portability among them.


Petr


> -----Original Message-----
> From: Greg Wilkins [mailto:gregw@mortbay.com]
> Sent: Thursday, November 30, 2000 11:21 PM
> To: jetty-discuss@egroups.com; tomcat-dev@jakarta.apache.org;
> servlet-interest@java.sun.com; servletapi-feedback@eng.sun.com
> Subject: 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<gregw@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
> 

Mime
View raw message