Comment 2 for bug 1531987

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.