Fix rails 2 support

@solenko noticed an issue with the way the gem is loaded in rails 2 #304

Bug fix and strict dynamic support

• Fix bug that can occur when useragent library version is older, resulting in a nil version sometimes.
• Add constant for strict-dynamic

Add support for setting two headers

v3.5.0

Version 3.5.0

Handle frame-src/child-src gracefully

3.4.0 the frame-src/child-src transition for Firefox.

Handle the child-src/frame-src transition semi-intelligently across versions. I think the code best describes the behavior here:

if supported_directives.include?(:child_src)
  @config[:child_src] = @config[:child_src] || @config[:frame_src]
else
  @config[:frame_src] = @config[:frame_src] || @config[:child_src]
end

minor fix to silence warnings when using rake

@dankohn was seeing "already initialized" errors in his output. This change conditionally defines the constants.

bugfix for boolean CSP directives

@stefansundin noticed that supplying false to "boolean" CSP directives (e.g. upgrade-insecure-requests and block-all-mixed-content) would still include the value.

referrer-policy support

While not officially part of the spec and not implemented anywhere, support for the experimental referrer-policy header was preemptively added.

Additionally, two minor enhancements were added this version:

1. Warn when the HPKP report host is the same as the current host. By definition any generated reports would be reporting to a known compromised connection.
2. Filter unsupported CSP directives when using Edge. Previously, this was causing many warnings in the developer console.

Cookie settings and CSP hash sources

3.2.0 Cookie settings and CSP hash sources

Cookies

SecureHeaders supports Secure, HttpOnly and SameSite cookies. These can be defined in the form of a boolean, or as a Hash for more refined configuration.

Note: Regardless of the configuration specified, Secure cookies are only enabled for HTTPS requests.

Boolean-based configuration

Boolean-based configuration is intended to globally enable or disable a specific cookie attribute.

config.cookies = {
  secure: true, # mark all cookies as Secure
  httponly: false, # do not mark any cookies as HttpOnly
}

Hash-based configuration

Hash-based configuration allows for fine-grained control.

config.cookies = {
  secure: { except: ['_guest'] }, # mark all but the `_guest` cookie as Secure
  httponly: { only: ['_rails_session'] }, # only mark the `_rails_session` cookie as HttpOnly
}

SameSite cookie configuration

SameSite cookies permit either Strict or Lax enforcement mode options.

config.cookies = {
  samesite: {
    strict: true # mark all cookies as SameSite=Strict
  }
}

Strict and Lax enforcement modes can also be specified using a Hash.

config.cookies = {
  samesite: {
    strict: { only: ['_rails_session'] },
    lax: { only: ['_guest'] }
  }
}

Hash

script/style-src hashes can be used to whitelist inline content that is static. This has the benefit of allowing inline content without opening up the possibility of dynamic javascript like you would with a nonce.

You can add hash sources directly to your policy :

::SecureHeaders::Configuration.default do |config|
   config.csp = {
     default_src: %w('self')

     # this is a made up value but browsers will show the expected hash in the console.
     script_src: %w(sha256-123456)
   }
 end

You can also use the automated inline script detection/collection/computation of hash source values in your app.

 rake secure_headers:generate_hashes

This will generate a file (config/config/secure_headers_generated_hashes.yml by default, you can override by setting ENV["secure_headers_generated_hashes_file"]) containing a mapping of file names with the array of hash values found on that page. When ActionView renders a given file, we check if there are any known hashes for that given file. If so, they are added as values to the header.

---
scripts:
  app/views/asdfs/index.html.erb:
  - "'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg='"
styles:
  app/views/asdfs/index.html.erb:
  - "'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY='"
  - "'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE='"

Helpers

This will not compute dynamic hashes by design. The output of both helpers will be a plain script/style tag without modification and the known hashes for a given file will be added to script-src/style-src when hashed_javascript_tag and hashed_style_tag are used. You can use raise_error_on_unrecognized_hash = true to be extra paranoid that you have precomputed hash values for all of your inline content. By default, this will raise an error in non-production environments.

<%= hashed_style_tag do %>
body {
  background-color: black;
}
<% end %>

<%= hashed_style_tag do %>
body {
  font-size: 30px;
  font-color: green;
}
<% end %>

<%= hashed_javascript_tag do %>
console.log(1)
<% end %>

Content-Security-Policy: ...
 script-src 'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg=' ... ;
 style-src 'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY=' 'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE=' ...;

Bug fix for regression

See #239

This meant that when header caches were regenerated upon calling SecureHeaders.override(:name) and using it with use_secure_headers_override would result in default values for anything other than CSP/HPKP.

Fix for `opt_out_of_all_protection` regression

See #235

idempotent_additions? would return false when comparing OPT_OUT with OPT_OUT, causing header_hash_for to return a header cache with { nil => nil } which cause the middleware to blow up when { nil => nil } was merged into the rack header hash.

This is a regression in 3.1.0 only.

Now it returns true. I've added a test case to ensure that header_hash_for will never return such an element.