On 24.08.2017 21:43, James H. H. Lampert wrote:
On 8/24/17, 11:35 AM, Mark Thomas wrote:
Tomcat will prevent access to anything in WEB-INF or META_INF.
Everything else is up to the app to control.
Note: You can place content in WEB-INF and include it from JSPs and
Servlets (and it will work) but direct access will not.
You might want to take a look in the Servlet spec for security constraints.
Thanks. I've just discovered security constraints, along with some material on
StackExchange's ServerFault board demonstrating how to create them. It's taken
a very
large load off my back.
So far, I've only scratched the surface of the subject.
There seems to be a good explanation here :
https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html
Am I correct in understanding that a security constraint in a context's web.inf
only
blocks access from outside? That the webapp itself still has full access to the
information?
As long as the webapp's way of accessing this data is via some local file access method,
yes. (I mean "open file; read from it; close file"). That's the webapp doing it, and
Tomcat doesn't even know about it, so Tomcat will not prevent it.
(These file's ownership and permissions may still prevent it).
And that if I give it a role name that hasn't been given to anybody in
tomcat-users.xml,
then nobody can get in at all? Can I set up a security constraint to just
unconditionally
deny all outside access, without even offering a sign-on dialog?
According to that same document mentioned above :
"If there is an authorization constraint but no roles are specified within it, the
container will not allow access to constrained requests under any circumstances."
The one problem that I see with this, is that you need a "positive" defense to protect
these files : you need to specify a URL-pattern that applies to the files which you want
to forbid (and which does not apply to the ones you want to leave accessible, like your
real JSP (or HTML) pages).
That means that any file that is NOT covered by your URL pattern, is left
accessible.
In a security-conscious way, it should be the opposite : anything which you do not
explicitly specify as accessible, should be non-accessible.
(Because even if you specify a correct pattern now, covering all the files
not-to-be-accessible, it is always possible for someone to put a file there later (and
carelessly), which does not match that pattern, and would ipso-facto be accessible again).
If you want better security, then do as Mark said, and put the files under webapp/WEB-INF/
or webapp/META-INF/, where *by default* they are not accessible. And modify the webapp to
search for them there.
It is also more efficient that way, because Tomcat does not have to start evaluating
security-constraints, and match the filenames with URL patterns (and neither do you).
Tomcat already, by default, checks each request URL to see if it contains /WEB-INF/ or
/META-INF/, and if it does, it is automatically NO, without looking any further.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
