Hello, thanks for all your suggestions and input and also Chris for digging into the underlying reason. As tomcat is running standalone I think I will leave it as it is. Setting up a reverse proxy or containerization for this reason sounds like overdoing it in this case.
I will take it as a "cosmetic imperfection" and maybe ask also the burpsuite-team if this finding is justified. I wish all a nice weekend! Thomas > -----Ursprüngliche Nachricht----- > Von: Roberto Benedetti <roberto.benede...@dedalus.eu> > Gesendet: Samstag, 16. September 2023 11:46 > An: Tomcat Users List <users@tomcat.apache.org> > Betreff: R: HSTS on 401 / error pages > > 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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KKKKKKKKKKK > > 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 > > B > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KKKKKKKKKKCB [ X ܚX KK[XZ[ > > \ \ ][ X ܚX P X ] > \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ > > \ \ Z[ X ] > \X K ܙ B
