BadgeApp: Look for gems to harden

[david-a-wheeler]

Consider using gems to harden BadgeApp.

In particular, look at "secureheaders" https://github.com/twitter/secureheaders - this creates hardened HTTP headers that hardens against many attacks. We'll need to be careful to ensure that the development environments still work :-).

[altonius]

Is this a criteria in either our current or future badges? if not we should probably add it to at least one of them.

Altonius

On Sat, 24 Oct 2015 at 09:32 David A. Wheeler notifications@github.com wrote:

Consider using gems to harden BadgeApp.

In particular, look at "secureheaders" https://github.com/twitter/secureheaders - this creates hardened HTTP headers that hardens against many attacks. We'll need to be careful to ensure that the development environments still work :-).

— Reply to this email directly or view it on GitHub https://github.com/linuxfoundation/cii-best-practices-badge/issues/103.

[david-a-wheeler]

altonius, you make a good point. We might even make that a change for the current badge. So I've added issue #125 to track this as a possibility. If you have ideas, especially about how to word it in a general way, please contribute your thoughts on issue #125.

[david-a-wheeler]

I've been holding off on adding the secure_headers gem created and maintained by Twitter, even though it looks very promising. One reason is because I've been waiting for its upcoming 3.0.0 release. Upgrading secure_headers to 3.0 is an interface-breaking change.. but it's also worth using 3.0.0. In particular secure_headers 2.X is implemented by using a series of before_headers; this is horribly inefficient (adding 8 for every request) and risks headers not getting set in certain errors. Version 3 sets headers in the rack middleware, which is faster and more robust, and these values get cached (!). So rather than add a version with known issues and backwards incompatibility, it seems better to wait a little and just add the 3.0.0 release.

As of this time 3.0.0 hasn't been released. Release 3.0.0.pre2 was released on December 22, 2015. We normally only install full releases (not pre-releases) via Rubygems. I expect that to be relatively soon, but it's impossible to be certain.

There are alternatives, e.g., rack-secure_headers. That one is less capable, though. In particular, it lacks Content Security Policy (CSP) and HTTP Public Key Pinning (HPKP). It'd be nice to have a single gem that handles all of these at once.

Note that we could also consider rack-ssl-enforcer to force all cookies to be secure. Not a big deal, but why not.

In short: I'm currently still waiting for the full release of 3.0.0 for secure_headers. I expect that since this will embed into rack (and not really Rails) this should work fine with the upcoming upgrades in Rails 5.

[david-a-wheeler]

Once we add an HTTP header hardening gem, we should probably document in the security.md document a crosswalk between our configuration and the OWASP list of useful HTTP headers.

We can also check our headers using Check your headers.

[david-a-wheeler]

As of today, the secure_headers 3.X branch is still not in RubyGems. See: https://rubygems.org/gems/secure_headers

I've asked the secure_headers developers when they intend to release: https://github.com/twitter/secureheaders/issues/210

[david-a-wheeler]

Here's the current info from oreoshake: "Thanks for the interest. I am getting ready to pull the trigger, but I'm being extra cautious since this is such a significant rewrite. Some of the design is still being hammered out and may change soon. Specifically we came across an issue where the protocol stripping (not present in the 2.x line) is causing an issue on safari (:fire: :hocho: :skull:) because safari's CSP support is terrible."

[david-a-wheeler]

3.0.0 just got released. See:

https://rubygems.org/gems/secure_headers/versions/3.0.0

[david-a-wheeler]

I've now tried out secure_headers. It works as advertized. However, while it turns on some other things, my main interest is in enabling Content Security Policy (CSP).

Unfortunately, we can't be as strong as we want to be. I can add it now, and it works, but only if I set:

script_src: %w('self' 'unsafe-eval' 'unsafe-inline'),
style_src: %w('self' 'unsafe-inline')

That's not a great thing. However, if we make this just 'self' then the auto-size of vertical textareas doesn't work, and Firefox reports "Content Security Policy: The page's settings blocked the loading of a resource at self ('default-src http://localhost:3000'). There are probably a number of other functions that also don't work.

We could add the hardening gem with an extremely weak CSP policy, and then slowly work to harden things further.

[david-a-wheeler]

We have now added a hardening gem, and we've locked down the HTTP headers to some extent. It'd be good to improve those headers, but since that's a different focus, I'm going to create another issue tracker to focus on just that.