Add various standard security policy as recommended by Mozilla

[mscherer]

While trying to see how much we would score on https://observatory.mozilla.org/,
I stumbled on various headers that would help and prevent whole class of attack,
such as clickjacking.

However, the most interesting settings would be to disable XSS with inline-javascript,
and this would likely requires auditing all websites first.

[duck-rh]

As you say there are settings not easy to add, and also this can change with time if new problems are found and new settings are possible. So instead of this approach, I would propose to have an incremental security level.

This one would be 0, level 1 would add more settings and future level would introduce potential breaking but useful changes. So once a site has been tested for a better level (preferably the latest defined), then the level can be setup in the playbook accordingly; each website would have its own setting to avoid breaking production and still allow upgradeability.

[mscherer]

I do not see security level as a good abstraction. The problem we have is likely a suite of boolean to be set or unset, and a number is not gonna express the required nuance (as I assume you do not propose to use a bitfield)

However, maybe this role is not the right place for that settings as that depend on the web software behind. So the setting should be pushed there either in a specific per software role (like jenkins), or maybe directly upstream (after all, jenkins can push the header as much as we can).

So, I think we can keep:

• X-Content-Type-Options: nosniff

We can also keep (for now, this is deprecated):

• X-Frame-Options

And just switch to append for:

• Content-Security-Policy

so we can append more in different roles (and or let the web software do it)

[duck-rh]

I thought your goal was to enforce step by step a global security level, but it seems I misunderstood the PR's intent.

My proposal is not about selecting features, but about having some API level which allows to upgrade to the level the site is able to work on and avoid breaking things before being tested. With this method there is no flavour, a site stays on lower level until it is fixed to work safely (upstream tickets/patches) as per our policy, or we change the policy to downgrade a problematic setting.

You often told me my roles had too many settings and should be simplified. If we create flags then we're gonna have a lot of them. Also you're gonna stick forever to your implementation and create more flags in case of mistake or need to improve the setting, in order to not break existing site using it.

[mscherer]

Yup, that's why I do not like the idea of flags either, but the discussion with you made me realise that we must push that lower in the stack, and this doesn't belong to the httpd role. This is not sustainable to do that at the httpd level, at least for anything that do not depend on the configuration of httpd.

I also need to read a bit more about modern attacks too to see if we need that or not.

[duck-rh]

ok, so we need to express this somehow, and make it available in some way usable to various softwares, whatever TLS lib they use. Seems quite complex but interesting. We should discuss this elsewhere.

[mscherer]

The commit is about http headers, I suspect the comment about tls lib was meant for another bug ? (cause I kinda do not understand the relationship, besides "security related")

[duck-rh]

Hum, yes, I thought it was also looking at TLS settings, I was mistaken.

As for this then, lower in the stack would mean per-app I guess. Then maybe create another role to add these settings for a specific vhost/app?

[mscherer]

Yep, that's what I mean.

Ideally, I would love to have all settings from https://wiki.mozilla.org/Security/Guidelines/Web_Security to be sent by default, but some are highly dependent on the software. For example, Content-Security-Policy can be used to disable inline javascript, which is great. But iwould break jenkins, and so jenkins would need to be patched to fix that.

On the other hand, something like the Nosiff header seems generic enough to not requires customisation (but has less impact).

So on one hand, pushing everything to application is more sustainable, since they are the one who know what is safe and what is not. On the other hand, that's less work to push some in the Apache level rather than duplicating 10 times. So we have to decide which is which.