Forums Register Login

Tomcat access/security problem

+Pie Number of slices to send: Send
Hi,

I'm a relative Tomcat newbie with the following problem. I have a publicly
accessible servlet which runs some legacy .exe files. The files are in a subdirectory of webapps/<servlet context>/legacy/. The servlet has no trouble finding and executing these files, but to my surprise, anybody with a browser can browse into this subdirectory and download the executables. I want to prevent users from dowloading them. What's the best way to do this?

Many thanks,
Glenn
+Pie Number of slices to send: Send
In TOMCAT/conf/web.xml, look for the entry for DefaultServlet.
It has an attribute called "listings". If you set it to false, you will disable directory browsing.

Alternatively (and more portable), you could store those exe files under WEB-INF which can't be accessed directly from a browser (even if you know the filename).

Or, just store them outside of your webapps and use an absolute path to access them from within your servlet code.
+Pie Number of slices to send: Send
Thanks for the timely response, Ben. It seems that good programming practice
would have been to put the legacy directory under WEB-INF/ in the first place, right?

By the way, my poor man's solution was to put index.html files into the directories so the contents wouldn't be read.

Cheers,
Glenn
+Pie Number of slices to send: Send
Unless they were being shipped as part of the webapp, I would have opted to keep them outside of the app's directory structure altogether.

If they were being shipped with the webapp, I would have put them under WEB-INF.
+Pie Number of slices to send: Send
Yes, I was in the latter category. This issue could have been avoided if
I had understood what the WEB-INF directory was for (what does "INF" mean,
anyway?). Section 9.5 of the 2.4 servlet spec says what I needed to
know, but it also says that the contents of WEB-INF/ are web.xml,
classes/, and lib/, so I was leery of putting something else in there.

I suppose the spec is just reflecting what is Java's greatest weakness
in my opinion, which is awkwardness in dealing with legacy issues.

Thanks again,
Glenn
+Pie Number of slices to send: Send
If moving them isn't an option, you could write a filter that screens out any requests for *.exe and returns a 404 status code.
+Pie Number of slices to send: Send
Hi Ben,

I did move my legacy/ directory to WEB-INF/ and everything is peachy.
However, since you mentioned it, I'm curious to know how/where such
a filter would go.

Thanks,
Glenn
+Pie Number of slices to send: Send
 

so I was leery of putting something else in there.



While the contents of WEB-INF (INF == info) must contain the expected content as described by the spec, there's no issue with putting other stuff in there too.

I routinely create a folder named 'pages' in WEB-INF and that's where I put all my JSPs (none of which should be directly referenced independently of their controllers). Anything else that shouldn't be directly referenced -- your exe files being a good example -- can also be placed there.

To keep things tidy, I never dump anything directly in WEB-INF itself, but always create a descriptive folder for whatever content is being hidden.
+Pie Number of slices to send: Send
 

I'm curious to know how/where such a filter would go.



You'd write the filter like any other class, put it under WEB-INF/classes (or in a WEB-INF/lib jar), and then declare it and which URL pattern(s) it applies to in the web.xml file.

The filter then gains control when the URL pattern is recognized and you can decide whether to proceed with the request or to take alternative action. In this case, returning the response with an error code of 'forbidden' might be most appropriate.
+Pie Number of slices to send: Send
Hi Bear,

Thanks for the two responses. It is reassuring to know that experts are
using the WEB-INF/ directory for other stuff. Also, your remark about
the filter led me to investigate whether I could use wild cards for url
patterns in web.xml, and lo, that is the case. Cool.

So that makes four ways to solve my problem. I'm finding that with
Tomcat there is usually "More Than One Way To Do It".

Cheers,
Glenn
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 624 times.
Similar Threads
deploying the J2EE Application - Specify JNDI Names
still cant compile the code
Restricting access to JSP - PLEASE HELP!!!
Tomcat example jsp working. Example servlet not working
This works at home tomcat but not where I want to deploy it!!!
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 15:37:03.