On 12/06/2023 19:13, jonmcalexan...@wellsfargo.com.INVALID wrote:
I'm asking because we are doing a review of our base settings. We are using the
CIS Benchmarks as a verification. One of these states to set matadata-complete
to true. We have never used this setting in the past and I am worried about
potential application breakage causing outages if we suddenly start setting
this setting. Is there any potential issue with using this and if so what?
I know it's a convoluted question, but trying to mitigate risk as much as
possible.
I've just done a quick review of the v1.2.0 benchmark for Tomcat 9.
1.1 Whoops. It tells you to delete the default ROOT web application with
no consideration of whether you might have replaced the default ROOT web
application with your own.
1.2 Incorrectly states the AJP connector is enabled by default. It has
been disabled by default since Feb 2020. The CIS doc was updated Sept
2022 more than 2 years later and it still got it wrong.
2.1 Only used in error pages and there are better ways to hide the
server version if you want to.
2.2 Not necessary - it isn't exposed to clients. Changing this will just
make debugging harder.
2.3 See 2.3
2.5 There are better ways to do this - configure a default error page.
2.6 There is an obvious copy/paste error in the audit section. One
wonders how thoroughly this document was reviewed / proof-read.
The remediation is missing critical detail. Depending on what else is in
the security constraint it may deny access to the entire application to
all users or it could bypass all other configured constraints and allow
all users unconstrained access.
2.7 Default is to send nothing which is better than the recommendation.
6.2-6.4 assumes direct access. If running behind a proxy these could be
VERY wrong.
7.3 An access log per context is "unusual". It will also miss all the
requests rejected before mapping occurs.
9 A recommendation to use a SecurityManager is more likely to break
stuff then make it more secure.
10.1 Only helps on Windows.
10.2 No. Per context configuration should be in a context.xml file not
server.xml.
10.3 Already present by default.
OK. I'm bored of this now. Suffice to say I don't recommend using the
CIS guide as anything more than a suggestion of things you might want to
look at but treat their recommendations with a large pinch of salt and
check the Tomcat docs for the relevant settings first.
I will skip forward and look at the metadata-complete recommendation
though...
10.18 Hmm. A library that provides a web-fragement.xml is a security
concern but we'll quietly ignore all the binary code that same JAR file
is providing that could be doing literally anything. Logically, it makes
no sense.
Personally, I don't like fragments or annotations but it has nothing to
do with security and everything to do with debugging. When things go
wrong it is very hard to figure out which filters and servlet a request
was mapped to and why if you don't have the full configuration in a
single web.xml file. For that reason, I'd recommend logging the
effective web.xml.
In terms of the recommendation, I'd ignore the metadata-complete
suggestion. If your application does use fragments and/or annotations
stuff will break.
Mark
Thanks,
Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
