If you have a fronting reverse proxy/load balancer (HAProxy, NGINX, Apache) you can use them to set HSTS and let Tomcat set the other security headers. If your application is running in a container (Kubernetes, Openshift, OKD), they all have the option to add HSTS in Ingress/Route. Again, the other security options are left to Tomcat.
We had the same issue and that's how we passed the pen-test. Roberto -----Messaggio originale----- Da: Peter Kreuser <l...@kreuser.name> Inviato: venerdì 15 settembre 2023 21:34 A: Tomcat Users List <users@tomcat.apache.org> Oggetto: Re: HSTS on 401 / error pages CAUTION - This e-mail originates outside of Dedalus. Be vigilant with content, links and attachments! d) !!! BTW: HSTS needs to be evaluated only once and then sticks in the browser! So unless the 401 is the first page ever, this change would not be really necessary. Peter > Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH) > <thomas.hoffm...@speed4trade.com.invalid>: > > Hello Christ, > >> -----Ursprüngliche Nachricht----- >> Von: Christopher Schultz <ch...@christopherschultz.net> >> Gesendet: Freitag, 15. September 2023 17:15 >> An: users@tomcat.apache.org >> Betreff: Re: AW: HSTS on 401 / error pages >> >> 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-cl >> class>ass> >>> <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 >> >> --------------------------------------------------------------------- > > Thanks for your elaboration! > The security headers change from time to time, true. > Maybe it would be possible to provide a kind of "http-header-valve" which can > be configured which headers to add? > Then you wouldn’t have a tight coupling and when headers change, you can > adjust the configuration without changing code. > It would not be as comfortable as the HttpHeaderSecurityFilter but more > flexible. > > Option d) would be to ignore the reported finding of the pen-testing > tool 😉 > > Greetings, > Thomas > > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KCB•È [œÝXœØÜšX™KK[XZ[ ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ] > ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ ˆ \Ù\œËZ[ ÛXØ] > ˜\XÚK›Ü™ÃBƒ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
