[arch-devops] [RFC] Better security through Content Security Policy and other headers.

[Jelle van der Waa]

Hi All,

Below is a proposal to increase our websecurity for *.archlinux.org

# Goal

Better security through Content Security Policy and other headers.

# How

Either sending CSP headers via nginx or modifying the web application to
send the correct headers. Configuring via nginx is probably the easiest
way to distribute these changes.

# Which sites

bugs.archlinux.org
bbs.archlinux.org
wiki.archlinux.org
git.archlinux.org
pkgbuild.com
pkgbuild.com/~*
mailman.archlinux.org
kanboard.archlinux.org
planet.archlinux.org
archlinux.org (django)
aur.archlinux.org

Excluded is security.archlinux.org, which already includes all of the
below headers via flask-talisman.

# Which headers

## X-XSS-Protection

The HTTP X-XSS-Protection response header is a feature of Internet Explorer,
Chrome and Safari that stops pages from loading when they detect reflected
cross-site scripting (XSS) attacks.

This is mostly superseded by CSP, but still is not harmfull to add.

add_header X-Xss-Protection "1; mode=block" always;

## X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker used by the server
to indicate that the MIME types advertised in the Content-Type headers should
not be changed and be followed.

Check bugtracker/archweb if this breaks attachments or other files which are download.

add_header X-Content-Type-Options "nosniff" always;

## X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not
a browser should be allowed to render a page in a <frame>, <iframe> or <object>
. Sites can use this to avoid clickjacking attacks, by ensuring that their
content is not embedded into other sites.

I don't believe we want to allow embedding our websites.

add_header X-Frame-Options "SAMEORIGIN" always;

## Content-Security-Policy

The HTTP Content-Security-Policy response header allows web site administrators
to control resources the user agent is allowed to load for a given page. With a
few exceptions, policies mostly involve specifying server origins and script
endpoints. This helps guard against cross-site scripting attacks (XSS).

This might differ a bit per site, Archweb for example requires unsafe-inline /
unsafe-eval for JavaScript and CSS. But all our loaded content should be from
the same origin and restricted. An example policy would be:

add_header Content-Security-Policy "default-src 'self'; style-src 'self'; font-src 'self'; form-action 'self';"

# Challenges

* inline JavaScript => archweb/aurweb => use a nonce or rewrite.
* inline CSS => archweb/aurweb => use a nonce or rewrite.
* unsafe-eval => this should never be allowed and should be fixed

# Verifying

The following website nicely shows the enabled security headers.

https://securityheaders.com/

More information about these headers can be found here.

https://scotthelme.co.uk/hardening-your-http-response-headers/

-- 
Jelle van der Waa