Secure j_security_check Response Headers |
Introduction
I was recently tasked with resolving a security issue with Apache Tomcat. The issue was that a series ofFilter
classes that were implemented in the web.xml
were being bypassed when we are using container managed security, e.g. j_security_check. The filters were adding security headers:
- X-Content-Type-Options: nosniff
- X-Frame-Options: SAMEORIGIN
- X-XSS-Protection: 1; mode=block
org.apache.catalina.filters.HttpHeaderSecurityFilter
. They duplicate the functionality, but the Apache version has a few more features. The Apache version is generally implemented in the web.xml
file for the whole server, e.g., <CATALINA_HOME>/conf/web.xml
. The code is really well written, and I would recommend using it except if you are using container managed security.
Issue
Container managed security,j_security_check, is implemented using aValve
. In particular, this intercepts the call and returns the form based login page which contains something like this:
The resulting response does not contain the headers noted above using either our custom filters, nor from the Apache HttpHeaderSecurityFilter
. Our automated security testing software, OWASP Zap caught it.
Solution
The easiest solution I came up with was to implement a couple of valves that add the selected response headers. I then added theValve
implementations to the <CATALINA_HOME>/conf/context.xml
. Adding them to the default context.xml
file allows them to be used on all applications deployed to the server. If you don't want applied to every application, you can add it to the context.xml
file in the individual project.The project can be found on Github here: tomcat-security-valves.
<dependency> <groupId>com.bluelotussoftware</groupId> <artifactId>tomcat-security-valves</artifactId> <version>1.0.0</version> </dependency>
An example application using the default Apache Tomcat realm is available here: tomcat-container-managed-security
0 comments :
Post a Comment