You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2020/03/23 22:10:22 UTC
Strange side effect of "antiClickJackingOption" clause in
"httpHeaderSecurity"
We recently enabled the httpHeaderSecurity filter globally (i.e., in
conf/web.xml) on several customer Tomcat servers, thusly:
> <filter>
> <filter-name>httpHeaderSecurity</filter-name>
> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> <init-param>
> <param-name>antiClickJackingOption</param-name>
> <param-value>SAMEORIGIN</param-value>
> </init-param>
> <async-supported>true</async-supported>
> </filter>
and now, it seems to be having a side effect on our mobile app, such
that the "dashboard" function of our product, while it continues to work
when accessed from a browser, is failing when accessed from our mobile
app. So far as we know, it's *only* the dashboard function (which is in
turn based on BIRT).
I know this sounds vague; it's vague because I haven't a clue what's
going on. I was hoping that somebody here might have some insights I
could pass on to our webapp/mobile app team.
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange side effect of "antiClickJackingOption" clause in
"httpHeaderSecurity"
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 3/24/20 2:25 PM, Christopher Schultz wrote:
. . .
> Your problem may stem from the same, related issues we were having. . .
Dear Mr. Schultz:
Thank you very much. I've passed on your reply to our webapp and
mobile-app team.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange side effect of "antiClickJackingOption" clause in
"httpHeaderSecurity"
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 3/26/20 12:54, James H. H. Lampert wrote:
> On 3/24/20 2:25 PM, Christopher Schultz wrote:
>> I don't understand exactly how X-Frame-Options (which is what
>> the HttpHeaderSecurityFilter is configuring) is being used by
>> your application, but I believe X-Frame-Options is essentially
>> being replaced by various features of Content-Security-Policy.
>> You may want to talk to your engineers about using one of those
>> versus the other; you may want to discontinue using the "anti
>> click-jacking" features of this filter altogether in favor of
>> something else.
>
> Dear Mr. Schultz (et al):
>
> Thanks. Our webapp team combined your answer with what we could
> glean from the customer's security audit, and has come up with a
> solution involving a Content-Security-Policy, using a class he
> added to the webapp. I'm not sure, but I think it can be built into
> the WAR file.
Glad to hear they have a fix.
> On our own Tomcat server, we have another webapp that cannot have
> clickjack protection via a HTTPHeaderSecurity filter with
>>
>> <param-name>antiClickJackingOption</param-name>
>>
>>
>> <param-value>SAMEORIGIN</param-value>
>>
>
> because it's specifically designed to go into a frame, in a page
> served from an entirely different server. Is that what the
> "ALLOW-FROM" option and the associated "antiClickJackingUri"
> parameter are for?
I would encourage you to read the Tomcat documentation and then go
down the rabbit hole a little bit by reading about the various headers
Tomcat is setting. The Tomcat documentation doesn't cover what all
those thing do; just what effect the config has on the headers. You
will learn better that they do by reading the header documentation
yourself than if I try to summarize here for you.
Sorry, I know that RTFM isn't the most convenient response, but I
think it's the best one for you.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5+HKoACgkQHPApP6U8
pFjNcxAAgnvS0ki7uf1aFtESZaikCd3LAU4Hl4hRvUFhcSk0vvuSoG+Hqu4snvTM
TPUblS2o95wbmlJlBqwPstYEL7mRVHCNUqXoe0dVTHc9vcz9Cgacs7xd3PR7B1nT
FEOZnuZSIxTQCOgwlZhx2Lvv/HHp3ja8NlEKs2mxVtb1N1PoxDMhIL2tSFHzTiJf
avHgS+wlc2872bum0IFrAIX619toKiVBARRVadXLKB7nXW9ToSkyV0tE78+n1BBI
/dPy3HcheoRluFkLTfZEwv6Mg1fPP2t//FW09h4aLNGlc6/C3jXi1b0P8sAyj8xz
A18psq0Y3qXw32ymSmEtOJSdEgU9ogGn52nR7aUDtAA6ccUTRJdXT7iMON4w+njb
FwBEkWtImbZGAcVuWhxLt1Ji0xJ7/XLRGokiIcc7iBji1VEo9TLk3eSmPaT/pZYz
aRg/vGw6PJJAUMoCHG2zDNXK01GMujUi0JCv2Awav4b6fs0YsbkfuF7d28eesH76
227E8AthiVE7YfIZPY++UtVtuvJNls7ii6QpRf5Tdu+AGDO5JDWh+FOgvDnUFzUY
J/hHYtFrPD/hxwyaaU/2t8ZAjJkSGzdu7A/eDidTXKdKAsvUBsoOO1w1o0RQTpE8
QU+fLT6tfO4vA6VvOM8OtvOvp+h91WUvoNk+bCj5IxIqib3F+T8=
=jgb7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange side effect of "antiClickJackingOption" clause in
"httpHeaderSecurity"
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 3/24/20 2:25 PM, Christopher Schultz wrote:
> I don't understand exactly how X-Frame-Options (which is what the
> HttpHeaderSecurityFilter is configuring) is being used by your
> application, but I believe X-Frame-Options is essentially being
> replaced by various features of Content-Security-Policy. You may want
> to talk to your engineers about using one of those versus the other;
> you may want to discontinue using the "anti click-jacking" features of
> this filter altogether in favor of something else.
Dear Mr. Schultz (et al):
Thanks. Our webapp team combined your answer with what we could glean
from the customer's security audit, and has come up with a solution
involving a Content-Security-Policy, using a class he added to the
webapp. I'm not sure, but I think it can be built into the WAR file.
On our own Tomcat server, we have another webapp that cannot have
clickjack protection via a HTTPHeaderSecurity filter with
> <param-name>antiClickJackingOption</param-name>
> <param-value>SAMEORIGIN</param-value>
because it's specifically designed to go into a frame, in a page served
from an entirely different server. Is that what the "ALLOW-FROM" option
and the associated "antiClickJackingUri" parameter are for?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange side effect of "antiClickJackingOption" clause in
"httpHeaderSecurity"
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 3/23/20 18:10, James H. H. Lampert wrote:
> We recently enabled the httpHeaderSecurity filter globally (i.e.,
> in conf/web.xml) on several customer Tomcat servers, thusly:
>
>> <filter>
>>
>>
>> <filter-name>httpHeaderSecurity</filter-name>
>>
>>
>> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</f
ilter-class>
>>
>>
>> <init-param>
>>
>>
>> <param-name>antiClickJackingOption</param-name>
>>
>>
>> <param-value>SAMEORIGIN</param-value>
>>
>>
>> </init-param>
>>
>>
>> <async-supported>true</async-supported>
>> </filter>
>>
>
>
> and now, it seems to be having a side effect on our mobile app,
> such that the "dashboard" function of our product, while it
> continues to work when accessed from a browser, is failing when
> accessed from our mobile app. So far as we know, it's *only* the
> dashboard function (which is in turn based on BIRT).
>
> I know this sounds vague; it's vague because I haven't a clue
> what's going on. I was hoping that somebody here might have some
> insights I could pass on to our webapp/mobile app team.
As soon as I added sameSite=lax cookie policy to our development
server, our mobile app exploded. We have also had problems with CORS
which broke our mobile application as well.
Your problem may stem from the same, related issues we were having:
many mobile apps are actually web applications being "served" by a
"server" which responds to requests to "localhost". The site-origin
for the mobile application is therefore "localhost" and does not match
"example.com" whence the real data is being fetched.
I don't understand exactly how X-Frame-Options (which is what the
HttpHeaderSecurityFilter is configuring) is being used by your
application, but I believe X-Frame-Options is essentially being
replaced by various features of Content-Security-Policy. You may want
to talk to your engineers about using one of those versus the other;
you may want to discontinue using the "anti click-jacking" features of
this filter altogether in favor of something else.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl56erMACgkQHPApP6U8
pFgAZQ//bGXQV4fkWh5uafyFKvS4Dp5NH6WGUx89ekaFvbyqf3r2lGr2CCGtfdBO
aETEhE8GoYDivibF/hsy7AixWjlYTdFnzqKDBDtTffj5tRhNact8LBBSx0LJH0cE
KBa/AnoNmll70n0XHnxtSh0q6iKvT6IClbyJOLBERXRRdm9LWgO9DG/0mZdetaTa
cIFYwle3N9uLhA9U7fwsrOZQpnVRvETjHsk9wuLYEdNBWLeCxfZCThU8pRvDvxfp
oV9pF729LYJ6zg5y8aMNOvG8le60MIkl2hEonfPmXht1zhq8wIOPO8aegCJ3qKpL
CSYMM8CfdeBC0LL5GBYSejxXkNG31GKRujcH73bi894avoLh1Mfg7ZBfSXzZV3Pk
K4t6P/ZIL/FpfSX49HiMYC60xfEl2JS8UJPtGpqz1jOaoOPUQdo1n3JcmO2Isgze
3S1IVOkcrlMgxoWJxundOJnnAmEygfueu6gi73CtDLa+G0LUieX0OduCG13MQXI2
2o/nTrut1Jf2aGIiMKBhD2ce9JOXsbd6DYkChTonsAlcz8PnzE2sdM+aRO3nHkdc
bS9jyJPtvvSLIdS4EAB2lOtnoj5vTXBwQa24DDTw3TRfBhgMaBsIt8uuInqVQPTg
EMinOLYTPPHihnDUu/cnZKPgpyTwFVw2XRJW62Ay3sfIFTdHG0M=
=5GlS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org