0

I am working on some security alerts on one of our servers whereby a 'file download' JSP file is able to let a user download contents of WEB-INF for the web application (Which is located in the root folder of the site). It is a very crudely simple file, written in 2007, that uses java.io.FileInputStream on unsanitised input to return a file to the user.

The alert actually claimed that this was a directory traversal problem, which it is in one way as the following URI would download the web.xml for the user:

http://domain.com/filedownload.jsp?filename=../../WEB-INF/web.xml&filepath=some/directory/

Now obviously the 'directory traversal' part should be corrected by doing user input sanitising (Which this script does not yet do). However, the following URI also delivers the web.xml to the user, but input sanitisation for directory traversal would not help here, unless the sanitisation checks for 'WEB-INF' and other 'illegal' directories...

http://domain.com/filedownload.jsp?filename=web.xml&filepath=WEB-INF/

Is there a standardised way to prevent this in common servlet containers or does this need to be entirely managed by the developer of the code? I noticed that the Java 'normalize()' function would not strip out this directory from the user input.

I tried searching for an answer for this, but all I could find was information about preventing the 'serving' of WEB-INF directly, but nothing about preventing it from being accessed from a JSP file itself.

Thanks,

Tom...

Tom17
  • 345
  • 4
  • 14
  • Sanitization is not a correct approach, IMO. The main problem is that you should not let the users specify a file name and even less a file path. Let them only choose some ID stored in a database row, that contains the actual path to the file, for example. Or at the very least, only let them specify a file name, and look for this file in a well-defined base directory on the server. – JB Nizet Mar 16 '16 at 23:00
  • This is old old code and they will not be re-engineering a new solution to fix this as the site will be going away at some point. But they will be needing to mitigate this error in the existing code. I agree that they should not be letting the user specify the file. It's not designed for user input, but is, I believe, used for generating download links, albeit very badly... – Tom17 Mar 16 '16 at 23:01

1 Answers1

1

You say the JSP page is using java.io.FileInputStream to read the file. That is a standard Java class that is not aware of the fact that it is running inside a servlet container.

So java.io.FileInputStream will be able to access any file that can be accessed by the user process the servlet container (JVM) is running under. There's nothing you could configure in the servlet container to prevent that.

You might like to make sure that files in other areas of the filesystem completely unrelated to the servlet container can't be accessed, e.g. like "/etc/passwd".

Assuming you're running on Linux, what does this URL do:

http://domain.com/filedownload.jsp?filename=passwd&filepath=/etc/

If it does return the file, you've got a bigger problem! Perhaps the security software (not sure what you're using?) that created the alerts will prevent download. If not, operating system file permissions can help, as long as the web server isn't running under root or other privileged account, but that's a short-term emergency fix only.

So no, there there no standardised way to prevent this in common servlet containers, and yes, it does need to be entirely managed by the developer of the code.

When using java.io.FileInputStream, it's the responsibility of the writer / maintainer of the JSP page to ensure that only valid paths are accessed.

Karl Harbour
  • 76
  • 4
  • This is exactly the answer I was looking for. I wanted to be sure of this before I told the developers "FIX YOUR DAMN CODE!" :) Thanks! – Tom17 Mar 18 '16 at 22:07