Re: Security audit raises questions (Tomcat 7.0.93)
On 20/03/2020 22:18, James H. H. Lampert wrote: > On 3/18/20 4:03 AM, Mark Thomas replied to my questions: > >>> But I'm not sure (1) how security constraints interact with other >>> security constraints, and >> >> See section 13.8.1 of the Servlet 4.0 spec. >> >>> (2) whether they can go in the conf/web.xml as >>> well as individual webapps' web.xml files. >> >> Yes they can. > > Dear Mr. Thomas, et al.: > > Ok. I've finally gotten back to this, and I've found a copy of the > Servlet 4.0 spec, and read the entire 13.8 section. > > I'm not yet clear on how they interact with each other if they exist at > both the conf/web.xml level and the individual webapp level. > > Given a Tomcat server with several webapps running, including multiple > copies of the same webapp (call it A), each accessing different > underlying resources. > > Each copy of A has this: >> >> >> Logs >> Logs >> /logs/* >> /logs.jsp >> > /> > > The manager and host-manager have their "out-of-the-box" security > constraints. > > Another specialized webapp (call it "S") has no security constraints in > its web.xml. > > There is also a context that consists only of static content, with no > web.xml, and therefore no security constraints of its own. > > And conf/web.xml has no security constraints. > > Now, suppose I were to put this into conf/web.xml: > >> >> >> Suppress OPTIONS >> /* >> OPTIONS >> >> >> > > Would that (1) block OPTIONS globally, and (2) *not* get into any fights > with any of the individual webapp security constraints? Yes. The short version of 13.8 for this specific scenario is that all the constraints for the same method / URL pair are combined and, if one of those constraints contains an empty auth-constraint, that takes priority and access is blocked. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/18/20 4:03 AM, Mark Thomas replied to my questions:
But I'm not sure (1) how security constraints interact with other
security constraints, and
See section 13.8.1 of the Servlet 4.0 spec.
(2) whether they can go in the conf/web.xml as
well as individual webapps' web.xml files.
Yes they can.
Dear Mr. Thomas, et al.:
Ok. I've finally gotten back to this, and I've found a copy of the
Servlet 4.0 spec, and read the entire 13.8 section.
I'm not yet clear on how they interact with each other if they exist at
both the conf/web.xml level and the individual webapp level.
Given a Tomcat server with several webapps running, including multiple
copies of the same webapp (call it A), each accessing different
underlying resources.
Each copy of A has this:
Logs
Logs
/logs/*
/logs.jsp
The manager and host-manager have their "out-of-the-box" security
constraints.
Another specialized webapp (call it "S") has no security constraints in
its web.xml.
There is also a context that consists only of static content, with no
web.xml, and therefore no security constraints of its own.
And conf/web.xml has no security constraints.
Now, suppose I were to put this into conf/web.xml:
Suppress OPTIONS
/*
OPTIONS
Would that (1) block OPTIONS globally, and (2) *not* get into any fights
with any of the individual webapp security constraints?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/18/20 1:16 AM, Olaf Kock wrote: Are you sure that this is for tomcat, not for your own application? Actually, since on-screen it looks like one of ours, I was already leaning to that conclusion, and had brought it to the attention of our webapp developer. Thanks for all the responses and clarifications. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Security audit raises questions (Tomcat 7.0.93)
Hi JHHL
> security audit on the Tomcat server we maintain
My condolences. :-) We're gone through several scans over the past couple
years too. Yeah, it's a pain.
If you can get the report details, it may provide enough info to pinpoint the
exact problems. Checkmarx scanning software does, I think.
Also, a strategy I found helpful was to reduce the "attack surface". Get rid
of anything flagged that you don't use rather than trying to fix the issues.
> First, it found a cross-site scripting vulnerability.
For scans of our systems, the XSS vulnerabilities were poorly protected JSP
expression language, uh, expressions. :-) Using standard tag libraries to
wrap ${expressions} helped. Also, defining a custom sanitize function used in
JSP pages like ${fn:escapeXml(param.xxx)} satisfied requirements in the
negotiation process.
Something we did not get around to was moving the JSP files to the
WebContent\WEB-INF folder so they could not be called directly with injected
malicious parameters.
> Second, it found the HTTP DELETE method enabled.
Do you need it? Can you disable it?
> Fourth, it found the HTTP OPTIONS method enabled.
Again, do you need it? Can you disable it?
> the click-jacking vulnerability came up [...] just now set up
> the filter and filter-mapping in conf/web.xml, so that is
> hopefully taken care of in the next restart.
+1 :-)
--
Cris Berneburg
CACI Lead Software Engineer
-Original Message-
From: James H. H. Lampert
Sent: Tuesday, March 17, 2020 6:05 PM
To: Tomcat Users List
Subject: Security audit raises questions (Tomcat 7.0.93)
Ladies and Gentlemen:
One of our customers did a security audit on the Tomcat server we maintain on
their system, and it found a few issues:
First, it found a cross-site scripting vulnerability.
Second, it found the HTTP DELETE method enabled.
Third, it found a click-jacking vulnerability.
Fourth, it found the HTTP OPTIONS method enabled.
Back in October, the click-jacking vulnerability came up on another customer
box; I've found the thread, and just now set up the filter and filter-mapping
in conf/web.xml, so that is hopefully taken care of in the next restart.
But I have no idea what to do about the cross-site scripting vulnerability, or
the DELETE and OPTIONS methods, and I'm having trouble understanding the
materials I've found.
--
JHHL
This electronic message contains information from CACI International Inc or
subsidiary companies, which may be company sensitive, proprietary, privileged
or otherwise protected from disclosure. The information is intended to be used
solely by the recipient(s) named above. If you are not an intended recipient,
be aware that any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have received this
transmission in error, please notify the sender immediately.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 3/17/20 18:31, James H. H. Lampert wrote: > > On 3/17/20 3:18 PM, Martynas Jusevičius wrote: >> why should DELETE or OPTIONS not be enabled? They are standard >> HTTP methods. > > True, but (quoting the audit report) >> . . . [DELETE] may allow a remote attacker to delete arbitrary >> files . . . . With (undue) respect to the auditors, using the SHUTDOWN method may allow a remote attacker to shut down your server while the DOWNLOAD_DATABASE method may allow an attacker to download your whole database. > and (again quoting the report) >> Web servers that respond to the OPTIONS HTTP method expose what >> other methods are supported by the web server, allowing attackers >> to narrow and intensify their efforts. The entire point of the OPTIONS method is to advertise what is allowed. There are other ways to discover what is allowed: simply try everything and see what works. OPTIONS is an optimization which is essentially required by some protocols (e.g. WebDAV). If you don't need it, you can disable it. IIRC, JSPs "allow" all methods but they all end up calling service(...) and doing whatever the JSP is supposed to do (which is almost always a GET or POST handler). So just because DELETE and/or OPTIONS don't cause any errors doesn't mean that DELETE will actually delete a file. You can put a filter in place to reject all such requests, but if your application needs them then it will break your application. If your application does not need them then they are harmless, assuming your application does not have any exploitable vulnerabilities. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5yHrEACgkQHPApP6U8 pFgJdw/7BU4ojwCGAgpdVtykssD/vm18P7rnnyKREIYzRm1lwB/fi/T2fh0pV/hT 9+kiXpF7IArNnXBS2JnHOfABFlxDqHZJ6UHH7nRnU/nMUyZw61pn8AioF4r7LlKP vQnF8fT5+n8evKPjHkUiJoRNyH0V4DATOR9fuk9+4sjMj4WO+7pWbYRq/TWVTfrn APceEqdmyBiSXTMbhfT+CRXOAK6WGe8aIuM43ebpMw5f2x+EZmdr8cgWYu+tpwVJ pYzdG52Qjv8XaBEEtvQCnQC6c51sQYwOJ1EsMXkhmrsB6oEPy0A+CPsmSe4fGjCK 85RpZLBhZDxu/ScJ75C+agesTBbM7KXFTgn06mP1L2iUJMg41lpYWv5pzsqDUF81 wT9je9dfa+87ud5d9FG6E+4p4O/y9Sy1DWax48SLJaunqEMxxtq2yQ9etoZdM02r IR3n9CO+9PI+DrdkI8vLKEPI6NZDlroz3uqSqkhngmiyot6WOTLXIRfAYM6868qq s818lxrTi1TFu4ikrW3k+GbU7Z1rIzGkGjPyYGZGevvNTWJ9YCyHec9YuRhc78/Z wSFKQ2DgLS5/vqtkQ2EIZY/b5sB5t0xu0+0pQrWV0Tgak+788CPETe3nA5jaIQE1 yHNHpTTT2PU5oW6SaPvl5uNoGwkxIBHwjFyhWlf6+4GW/nGuXpY= =3Vwe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 18/03/2020 00:04, James H. H. Lampert wrote: > On 3/17/20 3:50 PM, Mark Thomas wrote: >> The XXS might be valid. I assume the tool provided a sample URL you >> could use to validate the finding. That should point you in the right >> direction but feel free to ask here if more help is required. > Near as I can tell, it did but it didn't provide a sample URL. > > Note that *all* I have is a PDF of the report, and I think the URL may > have gotten mangled by spanning a page-break. I've posted a screenshot > (with identifying information redacted) of what I'm looking at in the > report: > > https://www.flickr.com/gp/64159238@N03/02i78o I'll agree with Olaf. That doesn't look like a Tomcat file. Tomcat's error.jsp doesn't have a from parameter. > > As to DELETE and OPTIONS, you get no argument from me about whether a > DELETE will actually *do* anything (I've got a query out to our web > developer on that), and on restricting OPTIONS being a case of "Security > by obscurity"; however, this is a case of "The Customer is Always Right." > > I found a page on disabling HTTP methods with a security constraint: > > https://www.techstacks.com/howto/disable-http-methods-in-tomcat.html The issue with that constraint is that it blacklists unwanted methods rather than whitelisting acceptable ones. I'd go with something like: Limit methods /* GET HEAD POST > But I'm not sure (1) how security constraints interact with other > security constraints, and See section 13.8.1 of the Servlet 4.0 spec. > (2) whether they can go in the conf/web.xml as > well as individual webapps' web.xml files. Yes they can. > As I said, I've got a query out to our web developers about *our* > webapp, but does Manager make any use of DELETE or OPTIONS? DELETE, no. OPTIONS, only in the sense it supports it but it doesn't depend on it being enabled so disabling OPTIONS won't break the manager app. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 17/03/2020 23:30, Martynas Jusevičius wrote: > Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I > don’t think I used any config to enable it. By default, HttpServlet (which pretty much every servlet extends) returns a 405 for a DELETE. The Servlets that Tomcat implements either leave that unchanged or require explicit configuration (DefaultServlet, WebdavServlet) to allow the DELETE method. If an application (or a library / framework) wants to implement DELETE then they are free to do so and Tomcat won't stop them. The assumption is that the developers of that library / framework will either secure access appropriately and/or explain to their users how to do so. The only method Tomcat blocks by default is TRACE. Not because TRACE is insecure, it isn't, but because at least one browser implementation was (may be still is) dumb enough to process the response as HTML rather than plain text. And that creates security issues. Mark > > On Tue, 17 Mar 2020 at 23.50, Mark Thomas wrote: > >> On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" < >> jam...@touchtonecorp.com> wrote: >>> >>> On 3/17/20 3:18 PM, Martynas Jusevičius wrote: why should DELETE or OPTIONS not be enabled? They are standard HTTP >>> methods. >>> >>> True, but (quoting the audit report) . . . [DELETE] may allow a remote attacker to delete arbitrary files >>> . . . . >> >> There is a big difference between supporting a method (recognising it is a >> known HTTP method) and allowing it. >> >> Tomcat does not allow DELETE by default. Your app might but one assumes if >> it does the developers know what they were doing and secured it >> appropriately... >> >> Tomcat takes the view that OPTIONS should list all supported methods, not >> just methods allowed, for a given resource. >> >>> and (again quoting the report) Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts. >> >> That is a security by obscurity argument. The Tomcat devs have never given >> much ,(any?) weight to arguments made on that basis. >> >> The XXS might be valid. I assume the tool provided a sample URL you could >> use to validate the finding. That should point you in the right direction >> but feel free to ask here if more help is required. >> >> Mark >> >> >>> -- >>> JHHL >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 18.03.20 01:04, James H. H. Lampert wrote: > On 3/17/20 3:50 PM, Mark Thomas wrote: >> The XXS might be valid. I assume the tool provided a sample URL you >> could use to validate the finding. That should point you in the right >> direction but feel free to ask here if more help is required. > Near as I can tell, it did but it didn't provide a sample URL. > > Note that *all* I have is a PDF of the report, and I think the URL may > have gotten mangled by spanning a page-break. I've posted a screenshot > (with identifying information redacted) of what I'm looking at in the > report: > > https://www.flickr.com/gp/64159238@N03/02i78o > This issue, according to that screenshot, seems to be on an error.jsp. The only error.jsp that I could find in Tomcat 7.0.93 and 7.0.100 is in webapps/examples/jsp/security/protected/error.jsp, i.e. under /webapps/examples Are you sure that this is for tomcat, not for your own application? Looking at tomcat's jsp, it's as simple as it can be, takes no external input, and doesn't generate markup as the one you've posted. But just in case: That examples webapp probably shouldn't be deployed on production servers anyway (seeing it there, IMHO it'd be a good idea to not package it in this way in the first place, but that's a different story) Cheers, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/17/20 3:50 PM, Mark Thomas wrote: The XXS might be valid. I assume the tool provided a sample URL you could use to validate the finding. That should point you in the right direction but feel free to ask here if more help is required. Near as I can tell, it did but it didn't provide a sample URL. Note that *all* I have is a PDF of the report, and I think the URL may have gotten mangled by spanning a page-break. I've posted a screenshot (with identifying information redacted) of what I'm looking at in the report: https://www.flickr.com/gp/64159238@N03/02i78o As to DELETE and OPTIONS, you get no argument from me about whether a DELETE will actually *do* anything (I've got a query out to our web developer on that), and on restricting OPTIONS being a case of "Security by obscurity"; however, this is a case of "The Customer is Always Right." I found a page on disabling HTTP methods with a security constraint: https://www.techstacks.com/howto/disable-http-methods-in-tomcat.html But I'm not sure (1) how security constraints interact with other security constraints, and (2) whether they can go in the conf/web.xml as well as individual webapps' web.xml files. As I said, I've got a query out to our web developers about *our* webapp, but does Manager make any use of DELETE or OPTIONS? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I don’t think I used any config to enable it. On Tue, 17 Mar 2020 at 23.50, Mark Thomas wrote: > On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" < > jam...@touchtonecorp.com> wrote: > > > >On 3/17/20 3:18 PM, Martynas Jusevičius wrote: > >> why should DELETE or OPTIONS not be enabled? They are standard HTTP > >methods. > > > >True, but (quoting the audit report) > >> . . . [DELETE] may allow a remote attacker to delete arbitrary files > >. . . . > > There is a big difference between supporting a method (recognising it is a > known HTTP method) and allowing it. > > Tomcat does not allow DELETE by default. Your app might but one assumes if > it does the developers know what they were doing and secured it > appropriately... > > Tomcat takes the view that OPTIONS should list all supported methods, not > just methods allowed, for a given resource. > > >and (again quoting the report) > >> Web servers that respond to the OPTIONS HTTP method expose what other > >> methods are supported by the web server, allowing attackers to narrow > >> and intensify their efforts. > > That is a security by obscurity argument. The Tomcat devs have never given > much ,(any?) weight to arguments made on that basis. > > The XXS might be valid. I assume the tool provided a sample URL you could > use to validate the finding. That should point you in the right direction > but feel free to ask here if more help is required. > > Mark > > > >-- > >JHHL > > > >- > >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Security audit raises questions (Tomcat 7.0.93)
On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" wrote: > >On 3/17/20 3:18 PM, Martynas Jusevičius wrote: >> why should DELETE or OPTIONS not be enabled? They are standard HTTP >methods. > >True, but (quoting the audit report) >> . . . [DELETE] may allow a remote attacker to delete arbitrary files >. . . . There is a big difference between supporting a method (recognising it is a known HTTP method) and allowing it. Tomcat does not allow DELETE by default. Your app might but one assumes if it does the developers know what they were doing and secured it appropriately... Tomcat takes the view that OPTIONS should list all supported methods, not just methods allowed, for a given resource. >and (again quoting the report) >> Web servers that respond to the OPTIONS HTTP method expose what other >> methods are supported by the web server, allowing attackers to narrow >> and intensify their efforts. That is a security by obscurity argument. The Tomcat devs have never given much ,(any?) weight to arguments made on that basis. The XXS might be valid. I assume the tool provided a sample URL you could use to validate the finding. That should point you in the right direction but feel free to ask here if more help is required. Mark >-- >JHHL > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/17/20 3:34 PM, Martin Grigorov wrote: Reading the quoted text I'd suggest you to throw this tool in the bin. I hope you didn't pay for it. Are you suggesting that we throw a paying customer "in the bin?" It is not OUR audit; it is the CUSTOMER's audit (the report self-identifies as being "performed by InsightVM from Rapid7 LLC", which until a few minutes ago, I'd never heard of). And the customer is always right. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On Wed, Mar 18, 2020 at 12:31 AM James H. H. Lampert < jam...@touchtonecorp.com> wrote: > > On 3/17/20 3:18 PM, Martynas Jusevičius wrote: > > why should DELETE or OPTIONS not be enabled? They are standard HTTP > methods. > > True, but (quoting the audit report) > > . . . [DELETE] may allow a remote attacker to delete arbitrary files . . > . . > and (again quoting the report) > > Web servers that respond to the OPTIONS HTTP method expose what other > > methods are supported by the web server, allowing attackers to narrow > > and intensify their efforts. > Reading the quoted text I'd suggest you to throw this tool in the bin. I hope you didn't pay for it. Martin > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/17/20 3:18 PM, Martynas Jusevičius wrote: why should DELETE or OPTIONS not be enabled? They are standard HTTP methods. True, but (quoting the audit report) . . . [DELETE] may allow a remote attacker to delete arbitrary files . . . . and (again quoting the report) Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
Hi, why should DELETE or OPTIONS not be enabled? They are standard HTTP methods. On Tue, Mar 17, 2020 at 11:05 PM James H. H. Lampert wrote: > > Ladies and Gentlemen: > > One of our customers did a security audit on the Tomcat server we > maintain on their system, and it found a few issues: > > First, it found a cross-site scripting vulnerability. > > Second, it found the HTTP DELETE method enabled. > > Third, it found a click-jacking vulnerability. > > Fourth, it found the HTTP OPTIONS method enabled. > > Back in October, the click-jacking vulnerability came up on another > customer box; I've found the thread, and just now set up the filter and > filter-mapping in conf/web.xml, so that is hopefully taken care of in > the next restart. > > But I have no idea what to do about the cross-site scripting > vulnerability, or the DELETE and OPTIONS methods, and I'm having trouble > understanding the materials I've found. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Security audit raises questions (Tomcat 7.0.93)
Ladies and Gentlemen: One of our customers did a security audit on the Tomcat server we maintain on their system, and it found a few issues: First, it found a cross-site scripting vulnerability. Second, it found the HTTP DELETE method enabled. Third, it found a click-jacking vulnerability. Fourth, it found the HTTP OPTIONS method enabled. Back in October, the click-jacking vulnerability came up on another customer box; I've found the thread, and just now set up the filter and filter-mapping in conf/web.xml, so that is hopefully taken care of in the next restart. But I have no idea what to do about the cross-site scripting vulnerability, or the DELETE and OPTIONS methods, and I'm having trouble understanding the materials I've found. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
