Review HTTP headers to improve security

[Kristina Hoeppner]

We need to review our HTTP headers to improve security and check which ones we should include per default and which ones might need to be configurable. The review will include but is not limited to:

- Strict-Transport-Security
- Content-Security-Policy
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Server
- X-Powered-By
- X-Permitted-Cross-Domain-Policies
- Caching headers

Initial reports for X-XSS-Protection header by SaifAllah benMassaoud and Zeeshan.

[Robert Lyon (robertl-9)]

Looking into the list above I've done some initial research as to what these headers are used for to see if we need to add them

* Strict-Transport-Security
- Would need to be turned on for sites running https
- Could be problems for sites with 3rd party content - but most of that should be sorted out now
- Could be a problem with self-signed certificates

* Content-Security-Policy
- helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header
- deals with restricting script/style/image/ajax/font/object sources
- Probably not useful for mahara as we allow the fetching of things via the external media block

* X-Frame-Options
- currently set to: sameorigin

* X-XSS-Protection
- The role of this header is to re-enable the filter for this particular website if it was disabled by the user
- Deals with reflected XSS vulnerabilities
- When set as: X-XSS-Protection: 1; mode=block it will prevent page loading

* X-Content-Type-Options
- only options at the moment is 'nostiff'
- prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type

* X-Powered-By
- Exposes what php version you are using
- You can set expose_php = Off in your php.ini if you don't want it to send X-Powered-By header.

* X-Permitted-Cross-Domain-Policies
- setting: 'master-only' Used by Adobe Flash
- More info: https://www.perpetual-beta.org/weblog/security-headers.html#rule-8470-2-establish-a-cross-domain-meta-policy
- a 2014 example from twitter
<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
  <allow-access-from domain="twitter.com" />
 <allow-access-from domain="api.twitter.com" />
 <allow-access-from domain="search.twitter.com" />
 <allow-access-from domain="static.twitter.com" />
 <site-control permitted-cross-domain-policies="master-only"/>
  <allow-http-request-headers-from domain="*.twitter.com" headers="*" secure="true"/>
</cross-domain-policy>

* Caching headers
- Currently is like this: Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

- other options worth adding:
- private - A proxy will not cache a page if it is marked as "private"
- no-transform - option may be important for mobile users. Some mobile providers will compress or alter content, in particular images, to save bandwidth when re-transmitting content over cellular networks.

[Aaron Wells (u-aaronw)]

After reviewing Robert's suggestions and some input from our security manager at Catalyst, I've decided to implement these changes in Mahara core:

1. Add the following HTTP headers to all page loads.

X-XSS-Protection: 1; mode=block (Prevents the user from disabling the browser's XSS protections)
X-Content-Type-Options: nonsniff (Tells the web browser to use Mahara's provided mimetype for downloads rather than trying to guess it)
X-Permitted-Cross-Domain-Policies: master-only (Controls what domains Adobe Flash is able to request assets from. We need this because we allow users to upload arbitary SWF files, and although in Bug 1190788 we implemented measures to force those SWF files to be downloaded rather than served, adding this setting will provide additional security in case some bug allows an attacker to bypass Bug 1190788.)

2. Block the X-Powered-By header to prevent exposing the particular PHP version:

header_remove('x-powered-by');

3. Activate the "Strict-Transport-Security" header in situations where the site's web root is HTTPS. This sets a kind of meta-cookie that tells the browser to only use HTTPS for accessing this domain name, for a specified future period of time. This helps guard against a man-in-the-middle attack where a site's first page is loaded via HTTPS but then the attacker forces it to redirect to HTTP on future page loads.

*However* this one's a little tricky, because if you activate in a situation where it's not wanted, it'll screw up other sites on the same domain. For instance, if a site were serving Mahara on https on one path on a domain, and Moodle on http on another path on the same domain (i.e. https://example.com/mahara and http://example.com/moodle) this would mess them up.

So probably what we should do here, is have Strict-Transport-Security be an admin setting, off by default. And if your site's wwwroot is HTTPS, then we show an admin warning advising you to turn this setting on unless you need it to be turned off.

4. Content-Security-Policy is tricky, because it sets detailed rules about what sorts of resources are allowed to be loaded from other domain names, and so an appropriate policy may change depending on site customizations or third-party plugins. So probably the best course here, is that we write a "works for a standard mahara site" policy which we'll apply on mahara.org via Apache or Nginx settings. And then we can document that on wiki.mahara.org.

And perhaps for a future release we can add this basic policy as a config-defaults default setting, and try to auto-detect third-party plugins or customizations that suggest the admin may need to customize it, and give them a warning if so.

[Mahara Bot (dev-mahara)]

Patch for "master" branch: https://reviews.mahara.org/6009

[Aaron Wells (u-aaronw)]

On further reflection, I decided not to include the "Strict-Transport-Security" header in Mahara core. It has too much potential to cause problems for site admins. If one of them did want to serve HTTP & HTTPS content off the same domain (i.e. https://example.com/mahara & http://example.com/insecure/) they probably wouldn't notice this setting until after it was causing problems, and once they reached that point, there would be no easy way to roll back the problem. See http://stackoverflow.com/questions/10629397/how-to-disable-http-strict-transport-security

The only way to revert Strict-Transport-Security (ie. HSTS) once it has been sent out, is:

1. Wait out the max-age period
2. Have *all* your site users clear their individual browser caches
3. Have the HTTPS version of your site serve a Strict-Transport-Security page with max-age:0. (But, you have to keep this up until *all* affected visitors have been served a copy of it.)

Of course, this difficulty in reversing it is by design. That's the whole point of this setting!

But for us, because this setting will cause nearly irreversible problems for the few sites where it is not appropriate, it would be irresponsible of us to turn it on automatically.

[Mahara Bot (dev-mahara)]

Reviewed: https://reviews.mahara.org/6009
Committed: https://git.mahara.org/mahara/mahara/commit/29656f034ff0eefa19fb6a0c24f006ff3ef9e1f0
Submitter: Robert Lyon (<email address hidden>)
Branch: master

commit 29656f034ff0eefa19fb6a0c24f006ff3ef9e1f0
Author: Aaron Wells <email address hidden>
Date: Thu Feb 4 16:33:11 2016 +1300

Adding some HTTP headers for security (Bug 1531987)

X-XSS-Protection: Tells the browser not to disable XSS protection

X-Content-Type-Options: Tells the browser not to try to guess at
mimetypes of downloads

X-Permitted-Cross-Domain-Policies: Tells Flash & PDF not to trust
alternate crossdomain.xml files (which set the permissions on whether
this site allows itself to be accessed by scripts in Flash & PDF).
Prevents an attacker from uploading a more permissive crossdomain.xml

X-Powered-By: PHP by default sends this header with the current full
PHP version.

behatnotneeded: Selenium can't examine HTTP response headers

Change-Id: Ia2a6de971fc62b7d8806ad010aa0fbe37c1a7357

[Mahara Bot (dev-mahara)]

Patch for "15.10_STABLE" branch: https://reviews.mahara.org/6214

[Mahara Bot (dev-mahara)]

Patch for "15.04_STABLE" branch: https://reviews.mahara.org/6215

[Mahara Bot (dev-mahara)]

Reviewed: https://reviews.mahara.org/6214
Committed: https://git.mahara.org/mahara/mahara/commit/eacff74e9d4d36b580bc3042771ff005a5d492f1
Submitter: Robert Lyon (<email address hidden>)
Branch: 15.10_STABLE

commit eacff74e9d4d36b580bc3042771ff005a5d492f1
Author: Aaron Wells <email address hidden>
Date: Thu Feb 4 16:33:11 2016 +1300

Adding some HTTP headers for security (Bug 1531987)

X-XSS-Protection: Tells the browser not to disable XSS protection

X-Content-Type-Options: Tells the browser not to try to guess at
mimetypes of downloads

X-Permitted-Cross-Domain-Policies: Tells Flash & PDF not to trust
alternate crossdomain.xml files (which set the permissions on whether
this site allows itself to be accessed by scripts in Flash & PDF).
Prevents an attacker from uploading a more permissive crossdomain.xml

X-Powered-By: PHP by default sends this header with the current full
PHP version.

behatnotneeded: Selenium can't examine HTTP response headers

Change-Id: Ia2a6de971fc62b7d8806ad010aa0fbe37c1a7357
(cherry picked from commit 29656f034ff0eefa19fb6a0c24f006ff3ef9e1f0)

[Mahara Bot (dev-mahara)]

Reviewed: https://reviews.mahara.org/6215
Committed: https://git.mahara.org/mahara/mahara/commit/d45af6dc1626736f6e8f9a2fcc8e45f854ef974c
Submitter: Robert Lyon (<email address hidden>)
Branch: 15.04_STABLE

commit d45af6dc1626736f6e8f9a2fcc8e45f854ef974c
Author: Aaron Wells <email address hidden>
Date: Thu Feb 4 16:33:11 2016 +1300

Adding some HTTP headers for security (Bug 1531987)

X-XSS-Protection: Tells the browser not to disable XSS protection

X-Content-Type-Options: Tells the browser not to try to guess at
mimetypes of downloads

X-Permitted-Cross-Domain-Policies: Tells Flash & PDF not to trust
alternate crossdomain.xml files (which set the permissions on whether
this site allows itself to be accessed by scripts in Flash & PDF).
Prevents an attacker from uploading a more permissive crossdomain.xml

X-Powered-By: PHP by default sends this header with the current full
PHP version.

behatnotneeded: Selenium can't examine HTTP response headers

Change-Id: Ia2a6de971fc62b7d8806ad010aa0fbe37c1a7357
(cherry picked from commit 29656f034ff0eefa19fb6a0c24f006ff3ef9e1f0)

[Mahara Bot (dev-mahara)]

Reviewed: https://reviews.mahara.org/6216
Committed: https://git.mahara.org/mahara/mahara/commit/ef64adaab69ddcee5f128c5fcb5e3d340b649d9b
Submitter: Robert Lyon (<email address hidden>)
Branch: 1.10_STABLE

commit ef64adaab69ddcee5f128c5fcb5e3d340b649d9b
Author: Aaron Wells <email address hidden>
Date: Thu Feb 4 16:33:11 2016 +1300

Adding some HTTP headers for security (Bug 1531987)

X-XSS-Protection: Tells the browser not to disable XSS protection

X-Content-Type-Options: Tells the browser not to try to guess at
mimetypes of downloads

X-Permitted-Cross-Domain-Policies: Tells Flash & PDF not to trust
alternate crossdomain.xml files (which set the permissions on whether
this site allows itself to be accessed by scripts in Flash & PDF).
Prevents an attacker from uploading a more permissive crossdomain.xml

X-Powered-By: PHP by default sends this header with the current full
PHP version.

behatnotneeded: Selenium can't examine HTTP response headers

Change-Id: Ia2a6de971fc62b7d8806ad010aa0fbe37c1a7357
(cherry picked from commit 29656f034ff0eefa19fb6a0c24f006ff3ef9e1f0)