tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Algesten <>
Subject WebdavServlet and security constraints
Date Thu, 03 Jul 2003 10:01:36 GMT
In a recent project we cooperated with our client in building a site. 
They were doing static html files and we took some of them and turned 
into JSPs.

In order for our client to be able to update their site, we enabled 
webdav on the webapplication. However, we don't want them to be able to 
update our JSPs which lives in the same webapp as their static content. 
We see it as a security risk to be able to write arbitrary JSP code 
that gets executed on our servers.

The neatest way of doing this protection was in the web.xml:

<!-- This constraint makes sure no JSP files are overwritten but they 
      still be downloaded. Only "dangerous" http-methods are forbidden. 
<!--      <http-method>GET</http-method> -->
<!--      <http-method>OPTIONS</http-method> -->
<!--      <http-method>PROPFIND</http-method> -->
       <!-- No roles, which means no one is allowed -->

Which works a charm, however it does not protect us for MOVE 
operations. The webdav client can still create a file such as file.txt 
and rename it to file.jsp and then execute it. This is because when 
renaming file.txt to something else the HTTP request issues is MOVE 
/file.txt and only later in the XML blurb is the destination file 

Now really what I would like to do is to make a "move filea.txt 
fileb.jsp" from a security point to be equal to a "DELETE filea.txt" 
and "PUT fileb.jsp". If the user is allowed to do these two operations, 
then he/she is allowed to do the MOVE.

Is there a nice server side way of doing this security check? I don't 
think the servlet API exposes anything useful. The only generic way of 
doing it that I can think of is constructing URL objects that calls my 
own servlet (and of course the added grief of copying over security 
headers etc) with some URL parameter that tells the servlet that the 
operation is only for test.

The other way is to do a TC specific solution, if I only could get hold 
of the internal APIs I could easily check this. I found the 
SecurityConstraint object which resides in the StandardContext object. 
However these classes seems very internal to TC and I suspect there is 
no good way of getting hold of them from the WebdavServlet, right?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message