Move CSP from report-only to stop actions

[colinxfleming]

No description provided.

[colinxfleming]

Here's the sitch here: In application_controller we have a method called csp_headers as follows:

  def csp_headers
    response.headers['Content-Security-Policy-Report-Only'] =
      "default-src 'self'; " \
      "script-src 'self' www.google-analytics.com 'sha256-1kYydMhZjhS1eCkHYjBthAOfULylJjbss3YE6S2CGLc=' 'unsafe-eval'; " \
      "font-src 'self' fonts.gstatic.com; " \
      "style-src 'self' 'unsafe-inline'; " \
      'object-src; ' \
      "report-uri https://#{ENV['CSP_VIOLATION_URI']}/csp/reportOnly"
  end

That sha256-xxxxxxxxx line is a hash of the js, I believe, but our JS has changed a few times since then.

Steps to resolve:

• figure out how to regenerate that sha hash of our assets
• figure out whether there's a way we can refresh it as part of deployment

cc @mccabe615 , would love your thoughts here!

[mccabe615]

One option would be to switch to nonces instead of hashes for inline JS.

https://blog.mozilla.org/security/2014/10/04/csp-for-the-web-we-have/

[colinxfleming]

@DarthHater I'd love for you to go on a fishing expedition on this front and see what it would take to easily regen the the sha-hash, or set nonces, or just do something to get this back up to speed (it's currently a worst case scenario, but real, security hole). Let me know!

[colinxfleming]

#1102 implements secure_headers which rules. There are a few remaining CSP steps to handle here:
a) we should take steps to take any and all inline js out of the view layer, since those are going to consistently cause report violations
b) after that, we should switch the CSP violations procedure from reporting to stopping the action in the secure headers report URI, and the secure headers config generally.

If UJS affects this, which I don't think it does, let's discuss a different strategy.

[colinxfleming]

Tagging this out as futuretech since it hasn't moved in awhile.