Chris, this is what's happening with the globally configured HttpHeaderSecurityFilter:
curl -ik "https://localhost:8443/manager/"; HTTP/2 302 x-frame-options: DENY x-content-type-options: nosniff strict-transport-security: max-age=31536000 x-xss-protection: 1; mode=block location: /manager/html content-type: text/html content-length: 0 date: Thu, 14 Sep 2023 20:31:50 GMT curl -ik "https://localhost:8443/manager/html/"; HTTP/2 401 cache-control: private www-authenticate: Basic realm="Tomcat Manager Application" vary: accept-encoding content-type: text/html;charset=ISO-8859-1 content-length: 2499 date: Thu, 14 Sep 2023 20:32:00 GMT curl -ik "https://localhost:8443/xxx"; HTTP/2 404 strict-transport-security: max-age=31536000 x-frame-options: DENY x-content-type-options: nosniff x-xss-protection: 1; mode=block content-type: text/html;charset=utf-8 content-language: en content-length: 41 date: Thu, 14 Sep 2023 20:31:35 I assume it's the order of the filters? Authentication before HeaderSecurity maybe? It's not HSTS only.... What do you think? Peter > Am 14.09.2023 um 16:03 schrieb Thomas Hoffmann (Speed4Trade GmbH) > <thomas.hoffm...@speed4trade.com.INVALID>: > > 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(?) > >> 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. > > Thanks in advance! > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
