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 can
still be downloaded. Only "dangerous" http-methods are forbidden. -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Forbidden</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<!-- <http-method>GET</http-method> -->
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<!-- <http-method>OPTIONS</http-method> -->
<http-method>PATCH</http-method>
<!-- <http-method>PROPFIND</http-method> -->
<http-method>PROPPATCH</http-method>
<http-method>MKCOL</http-method>
<http-method>COPY</http-method>
<http-method>MOVE</http-method>
<http-method>LOCK</http-method>
<http-method>UNLOCK</http-method>
</web-resource-collection>
<auth-constraint>
<!-- No roles, which means no one is allowed -->
</auth-constraint>


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 specified.

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?

Martin


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to