[ZendTo] Http headers - audit requirements

[Guy Bertrand]

Victor,

I laughed when I saw your email.... >>> Header set Server "none-of-your-business"

However, I would not recommend putting "none-of-your-business" as the actual text.  Hackers couldn't care less about your headers, but they might take offense to your "none-of-your-business", or see it as a challenge.  It just might make your site a even more of a target.

For our Apache HTTPD server, your suggestion " Header set Server" did not work.  It seems that it is a Apache Httpd known bug, but I also found a note that "... the Apache devs said it is a won't fix issue".  I did not investigate this any further.

I did find a way to do it using mod_security and using the SecServerSignature directive, but then mod_security didn't like it when I tried to upload a file larger than 128Mb.  And I don't have time to tweak mod_security right now.  There is a slight learning curve, so it is a project for later.

And you are correct, the Content-Security-Policy I wrote still needs work, so I have updated it accordingly.  Any other suggestions??

**********************
Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com; connect-src 'self' 'unsafe-inline'; img-src 'self' 'unsafe-inline' data: ; font-src 'self' 'unsafe-inline'  https://fonts.googleapis.com https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; frame-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com"
**********************

On SecurityHeaders I got an A (not an A+)
On MozillaObservatory, I got a B+  (from an original B with my first content-security-policy)

Also, as my last footnote on this topic, I found this text on the Apache HTTPD web site: "... Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety."

But it makes the auditors happy.

Regards,

Guy


Guy Bertrand, M.Ing
Directeur informatique / IT Manager
EXELA TECHNOLOGIES
b: +1.514.392.4999 | m: +1.514.265.9754
1155, boulevard Robert-Bourassa, suite 500 | Montréal (Québec) CANADA H3B 3A7
www.ExelaTech.com | EXELA LinkedIn

Message: 3
Date: Mon, 30 Sep 2019 11:47:20 +0200
From: Viktor Steinmann <stony at stony.com>
To: Guy Bertrand via ZendTo <zendto at zend.to>
Subject: Re: [ZendTo] Http headers - audit requirements
Message-ID:
<WM!6c673eb4e2250e4a6eae398e47f38d130712e1e054c13c41f8f26075a12d55987c4813c7b6704613a4929cb3368217f2!@mx.jul.es>

Content-Type: text/plain; charset=utf-8; format=flowed

Hi Guy

This is quite helpful, I have basically the same requirements in terms of compliance and I'm running almost the same headers.

One additional headers I would recommend is

Header set Server "none-of-your-business"

which will hide the fact, that this is an Apache running. Of course you can put "Nginx" or whatever instead of "none-of-your-business" to confuse a potential attacker a little more... ;-)

The main issue remains the Content-Security-Policy, which is not yet where it should be. The default-src should in any case be "none" and specific overrides in script-src, style-src etc.. But even then, the "unsafe-inline" parts will give you bad ratings on Mozilla's Observatory (https://observatory.mozilla.org/). I already wrote about this on this mailing list some time ago and asked Jules to put all JavaScript and Styles into separate .js and .css files in order to get rid of the "unsafe-inline" parts. I guess it's just a lot of changes to implement, but that would be really helpful in getting security another notch up.

Kind regards,

Viktor
________________________________
Attention : le présent message et toutes les pièces jointes sont confidentiels et établis à l'attention exclusive du ou des destinataire(s) indiqué(s). Toute autre diffusion ou utilisation non autorisée est interdite. Si vous recevez ce message par erreur, veuillez immédiatement en avertir l'expéditeur par e-mail en retour, détruire le message et vous abstenir de toute référence aux informations qui y figurent afin d'éviter les sanctions attachées à la divulgation et à l'utilisation d'informations confidentielles. Les messages électroniques sont susceptibles d'altération. Exela Technologies et ses filiales déclinent toute responsabilité en cas d'altération ou de falsification du présent message.
________________________________
Please consider the environment before printing or forwarding this email. If you do print this email, please recycle the paper.

This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Exela Technologies, Inc. or its subsidiaries.

This email does not constitute an agreement to conduct transactions by electronic means and does not create any legally binding contract or enforceable obligation against Exela in the absence of a fully signed written agreement.