Thomas,
On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Chris,
-----Ursprüngliche Nachricht-----
Von: Christopher Schultz <ch...@christopherschultz.net>
Gesendet: Donnerstag, 14. September 2023 15:26
An: users@tomcat.apache.org
Betreff: Re: HSTS on 401 / error pages
Thomas,
Please start a new thread next time.
Sorry, I thought removing all content and subject is sufficient. Maybe the
message-id header is used internally(?)
Absolutely. That's what "reply" does on a mailing list...
On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello everyone,
I would like to get your opinion about the HttpHeaderSecurityFilter in
Tomcat.
I configured HSTS in Tomcat and it works well.
When I do a pen-test with burpsuite it complains that HSTS header is
missing on 401 responses.
I couldn’t find much information about whether HSTS makes sense for
error pages.
It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
expects the header.
Are there any pros and cons about sending HSTS on 401 response?
You should always return an HSTS header.
How have you configured your HttpHeaderSecurityFilter? What is causing the
401 response? Which application is responding with that status?
-chris
Here are the requested details:
SecurityFilter is set in the web.xml of the application:
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>hstsEnabled</param-name>
<param-value>true</param-value>
</init-param>
...
Further down in the web.xml is a constraint:
<security-constraint>
<web-resource-collection>
<web-resource-name>xxx</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>yyy</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
There is no frontend-server, tomcat is directly accessed from the browser.
It seems that burpsuite didn’t send authentication in the first place and this
resulted in 401.
If I use curl https://<domain>/ I get similar result:
< HTTP/1.1 401
< WWW-Authenticate: Negotiate
< Content-Type: text/html;charset=utf-8
< Content-Language: de
< Content-Length: 439
< Date: Thu, 14 Sep 2023 13:58:10 GMT
When providing credentials to curl, the following headers are also included:
< Strict-Transport-Security: max-age=31536000;includeSubDomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
I hope this information helps.
Authentication is checked before any filters run, because authentication
is performed by a Valve, all of which run before any Filters run.
I'm not sure there is a way around this without
a. Using a fronting server of some kind
b. Getting a change of some kind made to Tomcat
c. Hacking this yourself
(b) is probably the best option, though I'm not sure what the best form
of server-support for this would be.
Making HttpHeaderSecurity available in a Valve-packaging would do the
trick, but maybe this makes sense to add at a more fundamental level to
Tomcat. The problem is that HSTS is only one of many security-related
headers and maybe it's potential lifetime isn't that long. My guess is
that sometime in the near future, TLS will simply be required for all
web traffic. If we bake that kind of thing into core-Tomcat, it becomes
something we will need to un-bake in the future, and chefs can tell you
that un-baking things rarely works out well.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
