You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by ja...@touchtonecorp.com on 2019/10/02 05:34:36 UTC
Security issue involving HTTP response headers
We have a customer who is particularly concerned about security.
We just updated their Tomcat, which solved all the issues coming up in their security scan, except for one involving the following HTTP headers:
X-FRAME-OPTIONS
X-XSS-PROTECTION
X-CONTENT-TYPE-OPTIONS
and strict transport security.
The environment is Tomcat 7.0.93, JSSE, running on an AS/400.
Is this something to be fixed in a configuration file, or the webapp, or someplace else?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by Peter Kreuser <lo...@kreuser.name>.
Hi James,
Peter Kreuser
> Am 02.10.2019 um 08:05 schrieb <jo...@wellsfargo.com.invalid> <jo...@wellsfargo.com.invalid>:
>
> Tomcat 7.0.63 and above.
>
> Navigate to the tomcat conf directory and open the web.xml with a text editor.
>
> In the filter section of the web.xml add the following filter
>
> <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>
> </filter>
+1
Beware to go with the defaults in a local environment. Set the parameter includesubdomains of HSTS to false, or the browsers will redirect any other subdomain-site to https! Not easy to get rid of this afterwards!
If you need different values for the headers (x-frame-options), you may also copy these settings to your webapp‘s web.xml
Peter
>
> In the filter mapping section of the web.xml add the following.
>
> <filter-mapping>
> <filter-name>httpHeaderSecurity</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> </filter-mapping>
>
>
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexander@wellsfargo.com
>
>
> This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
>
> -----Original Message-----
> From: jamesl@touchtonecorp.com <ja...@touchtonecorp.com>
> Sent: Wednesday, October 2, 2019 12:35 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Security issue involving HTTP response headers
>
> We have a customer who is particularly concerned about security.
>
> We just updated their Tomcat, which solved all the issues coming up in their security scan, except for one involving the following HTTP headers:
>
> X-FRAME-OPTIONS
> X-XSS-PROTECTION
> X-CONTENT-TYPE-OPTIONS
>
> and strict transport security.
>
> The environment is Tomcat 7.0.93, JSSE, running on an AS/400.
>
> Is this something to be fixed in a configuration file, or the webapp, or someplace else?
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by logo <lo...@kreuser.name>.
Hi James,
see below:
Am 2019-10-21 23:34, schrieb James H. H. Lampert:
>> <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>
>> </filter>
>>
Mark mentioned it before, that can also go into your apps web.xml and
instead of activating it for the whole tomcat instance, can only apply
to your app.
You can also remove the antiClickJacking option
(antiClickJackingEnabled=false) or extend it like this:
X-Frame-Options: allow-from https://example.com/
see
https://developer.mozilla.org/de/docs/Web/HTTP/Headers/X-Frame-Options
But that will affect also your app.
BTW: if you add this only to your app, the system will still "fail" all
security scans, as most scanners will run on IPs or the root context and
then see that the headers are missing. So the other app will need a fix
too.
HTH,
Peter
>> In the filter mapping section of the web.xml add the following.
>>
>> <filter-mapping>
>> <filter-name>httpHeaderSecurity</filter-name>
>> <url-pattern>/*</url-pattern>
>> <dispatcher>REQUEST</dispatcher>
>> </filter-mapping>
>
> Before I installed the above filter on the customer box (which *only*
> serves the webapp for our product), I tested it on our own box. And
> seeing no immediate problems, I didn't bother to pull it out of our
> box.
>
> Then I discovered that another webapp sharing the Tomcat server on our
> box, one that *by design* is placed in a frame, in a page residing on
> another server, had stopped working. With the filter in place, it
> works fine if you go directly to the page, but it fails if you go to
> the page on the other server.
>
> That raises two questions:
>
> 1. Is there something I can set in the above code, in order to allow
> this webapp to appear in the aforementioned frame where it is supposed
> to appear, but not if it's put in a frame on some other arbitrary
> page, elsewhere?
>
> 2. Are there other side effects of the HTTP header security filter
> that I should know about? It seems that on the aforementioned customer
> box, something happened recently that seems to be keeping our webapp
> from exporting M$ Excel files to the user. We don't think it's related
> (and have reason to believe it isn't), but one never can tell, and it
> never hurts to ask.
>
> --
> James H. H. Lampert
> (As my freshman woodshop teacher in high school was fond of saying,
> "The only dumb question is the one that doesn't get asked.")
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
> <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>
> </filter>
>
> In the filter mapping section of the web.xml add the following.
>
> <filter-mapping>
> <filter-name>httpHeaderSecurity</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> </filter-mapping>
Before I installed the above filter on the customer box (which *only*
serves the webapp for our product), I tested it on our own box. And
seeing no immediate problems, I didn't bother to pull it out of our box.
Then I discovered that another webapp sharing the Tomcat server on our
box, one that *by design* is placed in a frame, in a page residing on
another server, had stopped working. With the filter in place, it works
fine if you go directly to the page, but it fails if you go to the page
on the other server.
That raises two questions:
1. Is there something I can set in the above code, in order to allow
this webapp to appear in the aforementioned frame where it is supposed
to appear, but not if it's put in a frame on some other arbitrary page,
elsewhere?
2. Are there other side effects of the HTTP header security filter that
I should know about? It seems that on the aforementioned customer box,
something happened recently that seems to be keeping our webapp from
exporting M$ Excel files to the user. We don't think it's related (and
have reason to believe it isn't), but one never can tell, and it never
hurts to ask.
--
James H. H. Lampert
(As my freshman woodshop teacher in high school was fond of saying, "The
only dumb question is the one that doesn't get asked.")
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by Mark Thomas <ma...@apache.org>.
On 02/10/2019 07:05, jonmcalexander@wellsfargo.com.INVALID wrote:
> Tomcat 7.0.63 and above.
>
> Navigate to the tomcat conf directory and open the web.xml with a text editor.
If you edit $CATALINA_BASE/conf/web.xml that will apply to every web
application deployed on the Tomcat instance. You may well want to
consider editing the web.xml files for each web application individually
instead.
Mark
> In the filter section of the web.xml add the following filter
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Security issue involving HTTP response headers
Posted by jo...@wellsfargo.com.INVALID.
Tomcat 7.0.63 and above.
Navigate to the tomcat conf directory and open the web.xml with a text editor.
In the filter section of the web.xml add the following filter
<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>
</filter>
In the filter mapping section of the web.xml add the following.
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President
Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexander@wellsfargo.com
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
-----Original Message-----
From: jamesl@touchtonecorp.com <ja...@touchtonecorp.com>
Sent: Wednesday, October 2, 2019 12:35 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Security issue involving HTTP response headers
We have a customer who is particularly concerned about security.
We just updated their Tomcat, which solved all the issues coming up in their security scan, except for one involving the following HTTP headers:
X-FRAME-OPTIONS
X-XSS-PROTECTION
X-CONTENT-TYPE-OPTIONS
and strict transport security.
The environment is Tomcat 7.0.93, JSSE, running on an AS/400.
Is this something to be fixed in a configuration file, or the webapp, or someplace else?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by ja...@touchtonecorp.com.
Thanks to all who have responded (especially Mr. Schultz), and thanks in advance to anybody else who responds. It will be a few more days before I can act on the information. I'm not ignoring any of you; I'm gathering information so I can solve the problem ASAP upon my return to work from my vacation.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security issue involving HTTP response headers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 10/2/19 01:34, jamesl@touchtonecorp.com wrote:
> We have a customer who is particularly concerned about security.
>
> We just updated their Tomcat, which solved all the issues coming up
> in their security scan, except for one involving the following HTTP
> headers:
>
> X-FRAME-OPTIONS X-XSS-PROTECTION X-CONTENT-TYPE-OPTIONS
>
> and strict transport security.
>
> The environment is Tomcat 7.0.93, JSSE, running on an AS/400.
>
> Is this something to be fixed in a configuration file, or the
> webapp, or someplace else?
Have a look here:
http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#HTTP_Header_S
ecurity_Filter
Upgrading wouldn't hurt, too.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2Wai8ACgkQHPApP6U8
pFjtpQ//c9T4+0GuaykoyC5q88NS43HbuTXiwG/JUWigPythuFOufxLh0bA4KfnY
6nfxr8TUAyyTjk6qIYQy/c7M1XdV/+Ybm4m/oqQWbt4u+1x7KUbuX9IL94Mlgrzg
nQXGy5ZrmArOpldXLjmYsiFaG3/3wiS9Zqy458XJQFMlSNwf/K/VGgUEJfViz9Eu
e3CVfbNaTdjlNZz9Z5tFoJibFCfYuQAV7ZYlRR7wQ9BTHzJsLtF91WdPsbcRErF8
ZbfE4PmdqF9u3Q3nbYvgw+BUhKd3XwvSCxB/JMX6EfGk05+z6zICzj6vOqRYF5ps
t91IOW2SzzataW4LSCduWKygmCcSt4EnNmNZOfZhii5aAMA9AHQN1onReqUVNeMO
/KfvmrRkZbd4kh9hRjvGZvJKkIPyNl/lIRDGLvnk5hH+0Rvgm33lolh9skg/TLGF
HmZqttmdnIG8xrKzBbjpN1i1K/zUdoFmm8ZlP8OWdyc0pFp36UU0ARwaaNDdAAIb
teRqLzCenH/g4Si91Uh0T1d9Re0ma9DhnhnBpLKFZ3yAAt5YQxd2mBQkjB3hLHhf
mxqIpsIQMX0M06ro/Zh++50vxjViaGGIslCPkVwPFRsx2C846flKuAFIVn1nKXFK
d9y+sKwG07ld1XCZcIVHS3ox/h30pDGJhuXpHgE5UpSTLxphK5M=
=Jk/+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org