Bug 56383 - Securing ErrorReportValve [PATCH]
Securing ErrorReportValve [PATCH]
Product: Tomcat 7
Classification: Unclassified
Component: Catalina
All All
: P2 enhancement with 25 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
: 52751 (view as bug list)
Depends on:
  Show dependency tree
Reported: 2014-04-10 14:01 UTC by Nick Bunn
Modified: 2014-05-08 11:32 UTC (History)
2 users (show)

Patch for ErrorReportValve (6.54 KB, patch)
2014-04-10 14:01 UTC, Nick Bunn
Details | Diff
Patch for ErrorReportValve_02 (9.29 KB, patch)
2014-04-11 04:23 UTC, Nick Bunn
Details | Diff
Patch for ErrorReportValve_03 (9.29 KB, patch)
2014-04-15 14:19 UTC, Nick Bunn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Bunn 2014-04-10 14:01:12 UTC
Created attachment 31507 [details]
Patch for ErrorReportValve

When the default error valve returns its report it publishes the tomcat version and some other troubleshooting data. This of course breaks security standards at some companies and also is published as a item that needs to be remediated when hardening tomcat(OWASP - goo.gl/Zr9xso ). When using the OWASP solution of replacing the serverInfo.properties file it can and will break tools/code that uses that information. 

Attached is the proposed enhancement to be able switch options to show minimal information back.

By adding the below will only return a html page with only the status. No CSS or title
<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" />

Currently, default is true for both so if users still want to see the current report nothing will have to change in there server.xml
Comment 1 Konstantin Kolinko 2014-04-10 16:57:28 UTC
Comment on attachment 31507 [details]
Patch for ErrorReportValve

1. Add getter methods?

2. Expose new attributes via JMX? 
(Update mbeans-descriptors.xml file in the same package)

3. Documentation?

(Update webapps/docs/config/valve.xml. A bit more work than usually, because ErrorReporValve is not documented there at all)
Comment 2 Nick Bunn 2014-04-11 04:23:48 UTC
Created attachment 31510 [details]
Patch for ErrorReportValve_02

*Getter methods
*Exposed new attributes via JMX? 
*Updated Documentation
Comment 3 Nick Bunn 2014-04-15 14:19:54 UTC
Created attachment 31529 [details]
Patch for ErrorReportValve_03

Changed the variables to protected from private
Comment 4 Nick Bunn 2014-04-23 13:34:02 UTC
Do i need to provide a patch for tomcat 6 and 8?
Comment 5 Violeta Georgieva 2014-04-24 07:35:50 UTC

I see that you are removing the CSS when showReport is false. Why is that?

When showServerInfo is false you are removing the whole footer. Why is that? You can remove only the text so that the page stays with the same look and feel.

Comment 6 Nick Bunn 2014-04-24 18:27:41 UTC
My first patch did actually keep the css. However, after talking more with my team at work and looking at what the TomEE team has done(doesn't have css as well), it was determined if i left it you would then know its tomcat so you would still have a possible security issue.

I just want to note you have to set both settings to false to remove the css. if you just disable the version you will see the css for the report part.
Comment 7 Violeta Georgieva 2014-04-25 11:16:19 UTC
Thanks for the report and the patch. This has been fixed in trunk for 8.0.6 and in 7.0.x for 7.0.54 onwards.
Comment 8 Konstantin Kolinko 2014-04-27 17:08:56 UTC
When both showServerInfo and showReport are false, the generated HTML will have no <title> element. If I remember the specs correctly a <title> is required.

A good alternative will be

                String.valueOf(statusCode), message))

// errorReportValve.statusHeader=HTTP Status {0} - {1}
Comment 9 Konstantin Kolinko 2014-04-27 18:19:32 UTC
(In reply to Konstantin Kolinko from comment #8)

Fixed, will be in 8.0.6 and 7.0.54.

I went with the standard title "Error report".

When I tried repeating the header text in the title, it looked bad for 404 errors.
Comment 10 Violeta Georgieva 2014-05-08 11:32:27 UTC
*** Bug 52751 has been marked as a duplicate of this bug. ***