Re: Security issue involving HTTP response headers

2019-10-22 Thread logo

Hi James,

see below:

Am 2019-10-21 23:34, schrieb James H. H. Lampert:


 httpHeaderSecurity
 
org.apache.catalina.filters.HttpHeaderSecurityFilter

 
 antiClickJackingOption
 SAMEORIGIN
 




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.


 httpHeaderSecurity
 /*
 REQUEST



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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Security issue involving HTTP response headers

2019-10-21 Thread James H. H. Lampert


 httpHeaderSecurity
 
org.apache.catalina.filters.HttpHeaderSecurityFilter
 
 antiClickJackingOption
 SAMEORIGIN
 


In the filter mapping section of the web.xml add the following.


 httpHeaderSecurity
 /*
 REQUEST



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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Security issue involving HTTP response headers

2019-10-03 Thread jamesl
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Security issue involving HTTP response headers

2019-10-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/2/19 01:34, jam...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Security issue involving HTTP response headers

2019-10-02 Thread Mark Thomas
On 02/10/2019 07:05, jonmcalexan...@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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Security issue involving HTTP response headers

2019-10-02 Thread Peter Kreuser
Hi James,



Peter Kreuser
> Am 02.10.2019 um 08:05 schrieb  
> :
> 
> 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
> 
> 
>   httpHeaderSecurity
>   
> org.apache.catalina.filters.HttpHeaderSecurityFilter
>   
>   antiClickJackingOption
>   SAMEORIGIN
>   
> 

+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.
> 
> 
>   httpHeaderSecurity
>   /*
>   REQUEST
> 
> 
> 
> 
> 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
> 
> jonmcalexan...@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: jam...@touchtonecorp.com  
> Sent: Wednesday, October 2, 2019 12:35 AM
> To: Tomcat Users List 
> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> B‹CB•È[œÝ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



RE: Security issue involving HTTP response headers

2019-10-02 Thread jonmcalexander
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


httpHeaderSecurity

org.apache.catalina.filters.HttpHeaderSecurityFilter

antiClickJackingOption
SAMEORIGIN



In the filter mapping section of the web.xml add the following.


httpHeaderSecurity
/*
REQUEST




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

jonmcalexan...@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: jam...@touchtonecorp.com  
Sent: Wednesday, October 2, 2019 12:35 AM
To: Tomcat Users List 
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Security issue involving HTTP response headers

2019-10-01 Thread jamesl
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org