[ZendTo] Http headers - audit requirements

Mon Sep 30 10:47:20 BST 2019

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

On 28.09.2019 03:18, Guy Bertrand via ZendTo wrote:
> Hello all Zendto users,
>
> Our corporate security and audit department recently asked me to make sure that our Zendto installation sent back a whole bunch of security HTTP headers.  I told them that a hacker won’t care about any headers you send back, because they don’t use browsers, but more command-line automated type tools.  It fell on deaf ears, and they told me that if I want to pass audit, I had to do this.  Sigh.
>
> So I’ll share what I was able to configure with the ZendTo distribution list to make the site pass the audit.  If you want to skip my verbose description, just go at the bottom of the email for the configs.
>
> In your typical ZendTo config/preferences.php file, there should be a section entitled “// Security HTTP headers”, with 3 paragraphs of comments and possibly only one configuration:
> ‘X-Frame-Options’ => ‘sameorigin’,
>
> That’s nice, but not enough.  I’ve been using https://securityheaders.com to test our web site, and obviously… the site failed miserably.
>
> So after a whole bunch of reading (https://geekflare.com/http-header-implementation/ was pretty good), tweaking and testing, I’ve come up with a list of HTTP headers that gave me an A score.  Yea!!
>
> Note that I preferred to do this in my web server's configuration, not ZendTo's preferences.php file.  But I did leave the X-Frame-Options in the preferences.php, just to see what would happen the next time I upgrade ZendTo.
>
> The really tricky one is Content-Security-Policy.  If you don’t configure it just right, some of the ZendTo pages will not work.  I finally got it to work.  However, when I look at the code, Jules has obviously used some other open source tools, which have references to other sites (ie: URL), which I have found are not used by ZendTo.  However, in the config file, I have put them in a comment section.
>
> If you are trying to work on Content-Security-Policy (possibly after an upgrade) and you are having issues, do not despair!  Instead of Content-Security-Policy, you can actually start with Content-Security-Policy-Report-Only, which will display any warnings or errors in your browser’s development console (if you know how to get to it), while allowing the pages to display properly.  At least, that is what I did until I got it to work.  You can tweak the config file accordingly and then share it with the rest of us.  Same with the public-key-pins and public-key-pins-report-only.
>
> I’m using Apache Httpd.  If you are using another http server, you will need to adapt the config for your server’s syntax.
>
> Hope this helps!  And Jules, get better, not soon, but right now!!
>
> Regards,
>
> Guy
>
> Guy Bertrand, M.Ing
> Directeur informatique / IT Manager
> EXELA TECHNOLOGIES
> ####################################################################################
>
>
> # cat /etc/httpd/conf.d/httpheaders.conf
> ####################
> # This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules.
>
> ServerTokens Prod
>
> #########################################
> # The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents (error messages, mod_proxy ftp directory listings, mod_info output, ...).
>
> ServerSignature Off
>
> #######################################
> # remove header X-Powered-By
>
> Header always unset "X-Powered-By"
> header unset "X-Powered-By"
>
> #######################
> # X-XSS-Protection sets the configuration for the XSS Auditor built into older browser. The recommended value was "X-XSS-Protection: 1; mode=block" but you should now look at Content Security Policy instead.
>
> Header set X-XSS-Protection "1; mode=block"
>
> #####################
> # HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS.
>
> Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"
>
> #######################
> # X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff".
>
> Header set X-Content-Type-Options nosniff
>
> #####################
> # WARNING! already included in ZendTo preferences.php file.  You can remove it from the preferences.php file and put it here.
>
> #Header always append X-Frame-Options SAMEORIGIN
>
> ############################
> # Using Adobe products like PDF, Flash, etc.? You can implement this header to instruct the browser how to handle the requests over a cross-domain. By implementing this header, you restrict loading your site’s assets from other domain to avoid resource abuse.
>
> Header set X-Permitted-Cross-Domain-Policies "none"
>
> #######################
> # Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. Analyse this policy in more detail. You can sign up for a free account on Report URI to collect reports about problems on your site.
> # To start, you can use Content-Security-Policy-Report-Only and use the development tools in your browser to investigate the reported warning and errors.  All pages will be displayed, even if in error.
>
> # NOTE: ZENDTO has references to the following, yet I have not found that I needed to allow them...yet
> #http://datatables.net
> #http://cookiesandyou.com
> #http://zendto.to
> #mailto://
> #https://info.smartmessages.net
> #https://fonts.googleapis.com
> #http://www.smarty.net
>
> #Header set Content-Security-Policy
> #Header set Content-Security-Policy-Report-Only
>
> Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://uploadit.exelatech.com:443;  script-src 'self'  'unsafe-inline' https://www.google.com https://www.gstatic.com; connect-src 'self'; img-src 'self' 'unsafe-inline' data: ;  font-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com;  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; frame-src 'self' https://www.google.com https://www.gstatic.com"
>
> ##########################################
> # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy.
>
> Header set Expect-CT "max-age=0"
>
> #########################
> # not configured yet, but we still pass audit
> #########################
> # HTTP Public Key Pinning. Minimize the man-in-the-middle (MITM) attacks risk by pinning certificate. This is possible with HPKP (HTTP Public Key Pinning) header.  You can pin the root certificate public key or immediate certificate. At the time of writing, HPKP currently works in Firefox and Chrome and support SHA-256 hash algorithm.
> # To start, you can use public-key-pins-report-only and use the development tools in your browser to investigate the reported warning and errors.  All pages will be displayed, even if in error.
>
> #public-key-pins
> #public-key-pins-report-only
>
> # not configured yet
>
> ########################
> # NEW HEADERS coming soon
> ########################
> # Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser.
>
> # Not configured yet.
>
> ########################
> # referrer-policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.
>
> # Not configured yet.
>
> ########################
> # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy.
>
> # Not configured yet.
> ________________________________
> 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.
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto