mahara-contributors team mailing list archive

[Aaron Wells <1531987@xxxxxxxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1531987

Title:
  Review HTTP headers to improve security

Status in Mahara:
  Confirmed
Status in Mahara 1.10 series:
  Confirmed
Status in Mahara 15.04 series:
  Confirmed
Status in Mahara 15.10 series:
  Confirmed

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1531987/+subscriptions