Leo Donahue - PLANDEVX wrote:
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Dynamic Security Constraints?
Addenda :
1) ... You'd have to think carefully of where you place these
files to download, so that Tomcat does not unwittingly provide the
possibility for a user to download such a file directly (bypassing the
login) by providing a URL that points to the file directly.
Not to change the subject, but I hear a lot of people talking about the point
you're making about where to place the file and unwittingly providing a URL to
access it outside of a security constraint.
Perhaps there is some design history to this that people used to do that I am
just missing, so could someone please enlighten me?
If I place a file in a webapp context of customerx, and restrict access to
everything in the customerx url pattern to a specific login, how can that URL
be accessed outside of a security check? Are people doing something else when
they deploy their apps that would allow the situation you are describing? Are
they creating a separate docBase?
Let me give one example :
Imagine that you have a front-end webserver like Apache httpd or IIS, and one back-end
tomcat on the same host.
Then imagine that you would be of the opinion that it must be more efficient to have the
front-end server serve any static content (pure html, images, stylesheets) directly,
rather than proxying this to Tomcat and having Tomcat deliver that content through the
connector etc..
But for maintenance reasons, it is still easier to have all this content in one single
application directory, together with your JSP pages and webapps, under Tomcat /webapps/myapp.
So you would think : hey, why do I not define a <Location> (or a "virtual directory" or
whatever IIS calls it) in my front-end server, allowing it to serve the static content of
my Tomcat /webapps/myapp directly ?
The problem with this, is that the front-end server, by default, has no idea that the
/WEB-INF/ and /META-INF/ directories are special to Tomcat, and may contain things that
you do not want to serve to the outside world. So if a request URL, at the front-end
level, looks like it addresses a static file like /webapps/myapp/WEB-INF/passwords.xml, it
will happily serve it directly, never even asking Tomcat's opinion.
You'd be amazed at how many people have come here with configurations which do exactly
that. And how many additional ones have never come here but have the same layout.
There are subtler cases, involving uppercase/lowercase sensitivity; or involving doing the
login under HTTPS, but the rest of the session not, etc..
You are right that in your case, if you define one separate webapp per customer, and each
webapp requires a login, and the files to download by one customer are within that
webapp's directory, you will not have a security problem.
On the other hand, if you want a single webapp, but each customer should be able only to
download his own files, then your setup must be a bit more careful, and the links that you
provide to one customer to access his file(s), should not be so that he can just change
one or two characters in it and download someone else's files.
And if all the files are in the same directory, you should not allow them to obtain a
"directory index" page.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
