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-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
>>
>> ---------------------------------------------------------------------
>
> 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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝ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
