AW: HSTS on 401 / error pages
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 > Gesendet: Samstag, 16. September 2023 11:46 > An: Tomcat Users List > 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 > Inviato: venerdì 15 settembre 2023 21:34 > A: Tomcat Users List > 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) > : > > > > Hello Christ, > > > >> -Ursprüngliche Nachricht----- > >> Von: Christopher Schultz > >> 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 > >>>> 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: > >>> > >>>httpHeaderSecurity > >>> >> class>org.apache.catalina.filters.HttpHeaderSecurityFilter >> class>ass> > >>>true > >>> > >>> hstsEnabled > >>> true > >>> > >>> ... > >>> > >>> Further down in the web.xml is a constraint: > >>> > >>> > >>> xxx > >>> /* > >>>
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 Inviato: venerdì 15 settembre 2023 21:34 A: Tomcat Users List 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) > : > > Hello Christ, > >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz >> 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 >>>> 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: >>> >>>httpHeaderSecurity >>>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter> class>ass> >>>true >>> >>> hstsEnabled >>> true >>> >>> ... >>> >>> Further down in the web.xml is a constraint: >>> >>> >>> xxx >>> /* >>> >>> >>> >>> yyy >>> >>> >>> >>> CONFIDENTIAL >>> >>> >>> >>> >>> 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:/// 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; m
Re: HSTS on 401 / error pages
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) > : > > Hello Christ, > >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz >> 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 >>>> 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: >>> >>>httpHeaderSecurity >>>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter >>>true >>> >>> hstsEnabled >>> true >>> >>> ... >>> >>> Further down in the web.xml is a constraint: >>> >>> >>> xxx >>> /* >>> >>> >>> >>> yyy >>> >>> >>> >>> CONFIDENTIAL >>> >>> >>> >>> >>> 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:/// 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
AW: AW: HSTS on 401 / error pages
Hello Christ, > -Ursprüngliche Nachricht- > Von: Christopher Schultz > 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 > >> 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: > > > > httpHeaderSecurity > > class>org.apache.catalina.filters.HttpHeaderSecurityFilter > > true > > > > hstsEnabled > > true > > > > ... > > > > Further down in the web.xml is a constraint: > > > > > > xxx > > /* > > > > > > > > yyy > > > > > > > > CONFIDENTIAL > > > > > > > > > > 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:/// 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
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 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: httpHeaderSecurity org.apache.catalina.filters.HttpHeaderSecurityFilter true hstsEnabled true ... Further down in the web.xml is a constraint: xxx /* yyy CONFIDENTIAL 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:/// 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
AW: AW: HSTS on 401 / error pages
Hello Shawn, > -Ursprüngliche Nachricht- > Von: Shawn Heisey > Gesendet: Freitag, 15. September 2023 03:56 > An: Tomcat Users List > Betreff: Re: AW: HSTS on 401 / error pages > > On 9/14/23 08:03, Thomas Hoffmann (Speed4Trade GmbH) wrote: > > Sorry, I thought removing all content and subject is sufficient. Maybe > > the message-id header is used internally(?) > > TL;DR: technical details about message threading. Not about Tomcat. > > This is what happens when you reply to an existing message for a new topic > rather than starting a brand new message: > > https://www.dropbox.com/scl/fi/6f6xqoj9ndznr1pwnluuk/bad-threading- > tomcat-user.png?rlkey=q6385e4fqyd2ngp97qgj4bj3y=0 > > There are headers in the message that facilitate threading that you can't > normally see. These are the relevant headers in the message you replied to: > > References: <9ebb0e5d-1794-92f6-9c9f- > 47a235a4e...@touchtonecorp.com> > <057e2b5435244011898683f843170...@speed4trade.com> > <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org> > <80c5af8d-d267-581a-0877-687413cd6...@apache.org> > <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net> > > In-Reply-To: 802edd438...@touchtonecorp.com> > Message-ID: > > .com> > > And these are the relevant headers in your reply: > > Message-ID: <62e04634351c4c62ae75848a77dac...@speed4trade.com> > References: <9ebb0e5d-1794-92f6-9c9f- > 47a235a4e...@touchtonecorp.com> > <057e2b5435244011898683f843170...@speed4trade.com> > <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org> > <80c5af8d-d267-581a-0877-687413cd6...@apache.org> > <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net> > > > .com> > In-Reply-To: > > .com> > > While some mail clients will create threads on the message subject, these > headers are the strictly correct way to show threads. We also see messages > where people send a reply to a thread by writing a new message with the > same subject. Clients that do threading properly will not show those > messages as part of the thread. > > Thanks, > Shawn > > Thanks for your explanation and I see that pressing "reply" causes issues. I already assumed that the mail headers are related to this. I will stick to "new message" in future! Have a nice day! Thomas
Re: AW: HSTS on 401 / error pages
On 9/14/23 08:03, Thomas Hoffmann (Speed4Trade GmbH) wrote: Sorry, I thought removing all content and subject is sufficient. Maybe the message-id header is used internally(?) TL;DR: technical details about message threading. Not about Tomcat. This is what happens when you reply to an existing message for a new topic rather than starting a brand new message: https://www.dropbox.com/scl/fi/6f6xqoj9ndznr1pwnluuk/bad-threading-tomcat-user.png?rlkey=q6385e4fqyd2ngp97qgj4bj3y=0 There are headers in the message that facilitate threading that you can't normally see. These are the relevant headers in the message you replied to: References: <9ebb0e5d-1794-92f6-9c9f-47a235a4e...@touchtonecorp.com> <057e2b5435244011898683f843170...@speed4trade.com> <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org> <80c5af8d-d267-581a-0877-687413cd6...@apache.org> <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net> In-Reply-To: Message-ID: And these are the relevant headers in your reply: Message-ID: <62e04634351c4c62ae75848a77dac...@speed4trade.com> References: <9ebb0e5d-1794-92f6-9c9f-47a235a4e...@touchtonecorp.com> <057e2b5435244011898683f843170...@speed4trade.com> <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org> <80c5af8d-d267-581a-0877-687413cd6...@apache.org> <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net> In-Reply-To: While some mail clients will create threads on the message subject, these headers are the strictly correct way to show threads. We also see messages where people send a reply to a thread by writing a new message with the same subject. Clients that do threading properly will not show those messages as part of the thread. Thanks, Shawn - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HSTS on 401 / error pages
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) > : > > Hello Chris, > >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz >> 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: > > httpHeaderSecurity > > org.apache.catalina.filters.HttpHeaderSecurityFilter > true > >hstsEnabled >true > > ... > > Further down in the web.xml is a constraint: > > > xxx > /* > > > > yyy > > > > CONFIDENTIAL > > > > > 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:/// 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 >
AW: HSTS on 401 / error pages
Hello Chris, > -Ursprüngliche Nachricht- > Von: Christopher Schultz > 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: httpHeaderSecurity org.apache.catalina.filters.HttpHeaderSecurityFilter true hstsEnabled true ... Further down in the web.xml is a constraint: xxx /* yyy CONFIDENTIAL 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:/// 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
Re: HSTS on 401 / error pages
Thomas, Please start a new thread next time. 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
HSTS on 401 / error pages
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? Thanks in advance! Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
