Add DSL for configuring Content-Security-Policy header by pixeltrix · Pull Request #31162 · rails/rails

pixeltrix · 2017-11-15T21:16:04Z

Pushing up to get feedback on implementation

Documentation
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Examples
Global config in an initializer:

# config/initializers/content_security_policy.rb
Rails.application.config.content_security_policy do
  p.default_src :self, :https
  p.font_src    :self, :https, :data
  p.img_src     :self, :https, :data
  p.object_src  :none
  p.script_src  :self, :https
  p.style_src   :self, :https, :unsafe_inline

  # Specify URI for violation reports
  # p.report_uri  "/csp-violation-report-endpoint"
end

# Report CSP violations to a specified URI
# For further information see the following documentation:
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only
# Rails.application.config.content_security_policy_report_only = true

Per controller configuration:

# Override policy inline
class PostsController < ApplicationController
  content_security_policy do |p|
    p.upgrade_insecure_requests true
  end
end

# Using literal values
class PostsController < ApplicationController
  content_security_policy do |p|
    p.base_uri "https://www.example.com"
  end
end

# Using mixed static and dynamic values
class PostsController < ApplicationController
  content_security_policy do |p|
    p.base_uri :self, -> { "https://#{current_user.domain}.example.com" }
  end
end

jeremy

Lovely. Thanks for digging in to this. Added comments on 1. protect_content method naming; 2. declaring the base content security policy rather than using a boolean flag to indicate whether to use :application as the default policy; and 3. separating policy definitions from policy enforcement decisions, moving report-only out to the controller.

Also, food for thought: should the base policy be applied to all HTML responses in a Rack middleware? Catching other mounted apps, static pages, error pages, etc.

jeremy · 2017-11-15T22:51:59Z

+      self.content_security_policies = PolicyCollection.new
+
+      config_accessor :default_protect_content
+      self.default_protect_content = false


Good spot to specify the app-wide policy. Since this is the base policy for the whole app, be definitive:

# Set the base policy config.action_controller.content_security_policy = :application # No app-wide policy config.action_controller.content_security_policy = nil

Agree with a single base policy so this becomes irrelevant.

jeremy · 2017-11-15T22:56:31Z

+            @policies.fetch(name).clone
+          rescue KeyError
+            raise ArgumentError, "Unknown content security policy: #{name.inspect}"
+          end


Dupes #fetch impl above.

Irrelevant now that collection is going away

jeremy · 2017-11-15T22:59:25Z

+        elsif values.first
+          @directives["sandbox"] = values
+        else
+          @directives.delete("sandbox")


What would the caller for this case look like?

It's if you need to disable the value on a controller basis, e.g.

class LegacyPagesController < ApplicationController content_security_policy do |p| p.sandbox false end end

jeremy · 2017-11-15T23:03:22Z

+      end
+
+      def report_only!(uri:)
+        @report_only = true


Would treat the policy itself and how it's enforced as separate concerns. Can hoist this (and header_name) out to the controller and handle in set_content_security_policy.

jeremy · 2017-11-16T01:17:57Z

+            directives.each do |directive, sources|
+              copy[directive] = sources.map(&:dup)
+            end
+          end


directives.transform_values { |sources| sources.map(&:dup) }

jeremy · 2017-11-16T01:20:01Z

+            MAPPINGS.fetch(source)
+          else
+            raise ArgumentError, "Unknown content security policy source mapping: #{source.inspect}"
+          end


Can incorporate the existence check into the fetch:

MAPPINGS.fetch(source) do raise ArgumentError, "Unknown content security policy source mapping: #{source.inspect}" end

jeremy · 2017-11-16T01:22:16Z

+            elsif sources
+              directive
+            else
+              nil


Appears that a directive sources will never be nil, should just be absent. Raise here?

This is when a directive is set to false - there's a compact operation that removes these nil values in header_value:

def header_value(context = nil) build_directives(context).compact.join("; ") + ";" end

jeremy · 2017-11-16T01:26:10Z

+
+          unless policy.empty?
+            self.content_security_policy = policy
+          end


Maybe an edge case, but it could be sensible to set the header even if the policy is empty, making it clear that we've set an empty policy rather than omitting it.

Yes, agreed.

jeremy · 2017-11-16T01:27:16Z

+          end
+        end
+
+        after_action :set_content_security_policy, unless: :content_security_policy_present?


Do we foresee a controller action providing a custom policy that should preclude the declared controller policy for that action?

The unless: :content_security_policy_present? was more about handling upgraded apps that may have set the header manually - didn't want to break them.

jeremy · 2017-11-16T01:33:26Z

+  policy :report_only, using: :application do |p|
+    p.report_only!(uri: "/csp-violation-report-endpoint")
+  end
+end


Not sure about this policy collection API for central definition of multiple policies. I think in practice we'll have a single base policy that's extended in controller subclasses. If there's a set of controllers that use a stricter policy, I'd probably start by mixing in a concern that sets the strict policy.

Agreed - a single base policy with overrides either in concern or a common parent controller class makes the implementation simpler and doesn't lose any flexibility.

pixeltrix · 2017-11-16T11:50:46Z

@jeremy thanks for the review - agree that we should generate the default policy for all HTML responses so will move the policy class out to Action Dispatch and then just have the override implementation in Action Controller.

kaspth

Minor nits, but overall on API 👍

kaspth · 2017-11-26T18:59:34Z

+
+      def content_security_policy_report_only(*args)
+        options = args.extract_options!
+        flag = args.empty? ? true : args.first.present?


Could this be simplified with some kwarg help?

def content_security_policy_report_only(report_only = true, **options) end

kaspth · 2017-11-26T19:03:54Z

+        if MAPPINGS.key?(source)
+          MAPPINGS.fetch(source)
+        else
+          raise ArgumentError, "Unknown content security policy source mapping: #{source.inspect}"


Could do:

MAPPINGS.fetch(source) do raise ArgumentError, … end

kaspth · 2017-11-26T19:05:26Z

+  p.style_src   :self, :https, :unsafe_inline
+
+  # Specify URI for violation reports
+  # p.report_uri  "/csp-violation-report-endpoint"


Extra space after p.report_uri.

kaspth · 2017-11-26T19:07:45Z

+# For further information see the following documentation
+# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
+
+Rails.application.config.content_security_policy do |p|


Should this config be commented out for upgrading apps? Or should it be loose enough that apps can upgrade seamlessly and get more security?

Do initializers get generated for upgrading apps automatically?

Okay, will investigate what the preferred solution is to be once the beta ships and it's easier to test against upgrading real world apps.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

- Followup of rails#31162

Fix CHANGELOG for CSP PR #31162 [ci skip]

dwightwatson · 2017-11-27T10:41:01Z

Is there a guide or any documentation on how to use this in development? For example, JavaScripts served through the asset pipeline or Webpacker (either precompiled or with the hot-reloading development server) are all HTTP and therefore left broken with the default configuration.

pixeltrix · 2017-11-27T10:58:05Z

@dwightwatson I thought that 'self' would allow HTTP assets served from the same domain and https: allows third party assets from HTTPS sources? I took the defaults from #24961 which is described as 'lenient'.

dwightwatson · 2017-11-27T11:17:03Z

@pixeltrix That's what I thought as well, and after digging further into it that appears to be correct.

The issue I'm seeing is related but has to do with unsafe-eval. Looks like Webpacker bundles up modules using the eval method and this default CSP configuration doesn't allow for that.

Should I open another ticket to follow this issue instead? It might require the CSP configuration to be altered to allow for Webpacker assets or Webpacker might need to be configured to bundle another way.

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' https:".

pixeltrix · 2017-11-27T11:22:53Z

@dwightwatson is it the webpacker gem that uses eval or webpack itself?

pixeltrix · 2017-11-27T11:25:10Z

@dwightwatson I wonder whether rails/webpacker#1011 is related? Can you change config.devtool to cheap-module-source-map and see whether that fixes your problem.

dwightwatson · 2017-11-27T11:29:13Z

I was just reading the same thing - yeah it looks like that configuration change fixes the issue, all working locally now. Is making that configuration the new default something that could be reconsidered?

pixeltrix · 2017-11-27T11:32:01Z

Is making that configuration the new default something that could be considered?

Possibly - will raise it in the Campfire channel.

ryenski · 2017-11-28T05:31:42Z

I'm also having this issue, using rack-livereload:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https:". Either the 'unsafe-inline' keyword, a hash ('sha256-rlZ58lcfumEQqoV6vyIbnvH6c7q0w93savs/e1DR0TA='), or a nonce ('nonce-...') is required to enable inline execution.

Refused to load the script 'http://localhost:35729/livereload.js?' because it violates the following Content Security Policy directive: "script-src 'self' https:".

pixeltrix · 2017-11-28T09:27:45Z

@crispinheneise the quick fix is to add :unsafe_inline to the p.script_src line in your content_security_policy.rb initializer, however you lose some of the security that the CSP gives you in preventing XSS attacks. Ideally the rack-livereload middleware would add a nonce to the script tags it injects and then modify the CSP header to add nonce-<randomvalue>. That would allow you to use live reload in development without affecting your production environment.

ryenski · 2017-11-28T15:54:45Z

This may be an edge case, or it might belong to rack-livereload - if so please ignore.

In order to get CSP to work with rack-livereload I had to add unsafe-inline as @pixeltrix mentioned. Plus, I also had to add a script_src for port 35729 and a connect_src directive for the web socket. This is only needed in development, so this is what I did in content_security_policy.rb:

  if Rails.env.development?
    p.script_src  :self, :https, :unsafe_inline, 'http://localhost:35729'
    p.connect_src 'http://localhost:35729', 'ws://localhost:35729'
  else
    p.script_src  :self, :https
  end

pixeltrix · 2017-11-28T16:10:04Z

@crispinheneise only issue is that change is that you'll only find out about your own app's use of inline scripts when you deploy to production 😟

Document in the guides the new middleware added in rails#31162 [ci skip]

nsingh · 2018-06-14T23:26:26Z

Hi @pixeltrix ,

Thanks for implementing CSP in Rails! We are still on Rails 5.0.6 so we had to backport your code to get things in motion.

I did have one question regarding the ability to set both headers:

POLICY = "Content-Security-Policy".freeze
POLICY_REPORT_ONLY = "Content-Security-Policy-Report-Only".freeze

Currently it seems like if Report-Only option is true, it takes precedence:-

def header_name(request)
  if request.content_security_policy_report_only
    POLICY_REPORT_ONLY
  else
    POLICY
  end
end

The CSP documentation says that both headers can be present in the same response and could have different policies.

I am wondering if this was deliberate and whether Rails has plans to honor both headers in the near future?

A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from rails#31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy

A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy

pixeltrix force-pushed the add-csp-config branch from cf2c4fb to e70f128 Compare November 15, 2017 21:19

jeremy reviewed Nov 16, 2017

View reviewed changes

pixeltrix force-pushed the add-csp-config branch 2 times, most recently from 9404f54 to 727c415 Compare November 20, 2017 12:01

kaspth approved these changes Nov 26, 2017

View reviewed changes

pixeltrix force-pushed the add-csp-config branch from 727c415 to b8f5120 Compare November 27, 2017 05:56

pixeltrix changed the title ~~[WIP] Add DSL for configuring Content-Security-Policy header~~ Add DSL for configuring Content-Security-Policy header Nov 27, 2017

Add DSL for configuring Content-Security-Policy header

456c3ff

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

pixeltrix force-pushed the add-csp-config branch from b8f5120 to 456c3ff Compare November 27, 2017 05:59

pixeltrix merged commit afc2b42 into master Nov 27, 2017

pixeltrix deleted the add-csp-config branch November 27, 2017 08:15

pixeltrix added a commit that referenced this pull request Nov 27, 2017

Add CHANGELOG.md entry for #31162 [ci skip]

723f29c

prathamesh-sonpatki added a commit to prathamesh-sonpatki/rails that referenced this pull request Nov 27, 2017

Added missing test for presence of CSP initializer

30a60b4

- Followup of rails#31162

prathamesh-sonpatki mentioned this pull request Nov 27, 2017

Added missing test for presence of CSP initializer #31238

Merged

prathamesh-sonpatki added a commit to prathamesh-sonpatki/rails that referenced this pull request Nov 27, 2017

Fix CHANGELOG for CSP PR rails#31162 [ci skip]

5910c1d

pixeltrix added a commit that referenced this pull request Nov 27, 2017

Merge pull request #31239 from prathamesh-sonpatki/fix-changelog-for-csp

f7dbc56

Fix CHANGELOG for CSP PR #31162 [ci skip]

renchap mentioned this pull request Nov 27, 2017

Discussion: integration with Rails 5.2 CSP feature github/secure_headers#375

Closed

ryenski mentioned this pull request Nov 28, 2017

Violates CSP unsafe-inline rule johnbintz/rack-livereload#71

Open

pixeltrix mentioned this pull request Nov 28, 2017

Rails 5.2 beta breaks javascript packs #31258

Closed

guilleiguaran mentioned this pull request Nov 28, 2017

Switch config.devtool from cheap-eval-source-map to cheap-module-source-map rails/webpacker#1046

Merged

mrhead mentioned this pull request Nov 29, 2017

Server-side generated JavaScript Responses aren't executed because of default Content Security Policy #31273

Closed

guilleiguaran mentioned this pull request Nov 30, 2017

Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' https:". #31298

Closed

This was referenced Dec 3, 2017

Provide a default Content Security Policy (CSP) that is lenient yet secure #24961

Closed

Add Content Security Policy(CSP) #15777

Closed

damhonglinh mentioned this pull request Jan 8, 2018

Fullpage redirect with JavaScript doesn't work in Rails 5.2 due to Content Security Policy Shopify/shopify_app#535

Closed

ghost mentioned this pull request Jan 26, 2018

Content Security Policy Conflict in Rails 5.2 mkhairi/alertifyjs-rails#5

Closed

claudiob added a commit to claudiob/rails that referenced this pull request Jan 30, 2018

Add ContentSecurityPolicy to list of middleware

5ea2d02

Document in the guides the new middleware added in rails#31162 [ci skip]

claudiob mentioned this pull request Jan 30, 2018

Add ContentSecurityPolicy to list of middleware #31828

Merged

pixeltrix mentioned this pull request Feb 19, 2018

Fix generation of empty content security policy #32054

Merged

jacobbednarz mentioned this pull request Jul 26, 2018

Adds support for configuring HTTP Feature Policy #33439

Merged

pragmaticsc mentioned this pull request Oct 25, 2020

Unable to set both Content-Security-Policy and Content-Security-Policy-Report-Only headers with current DSL. #40452

Closed

pragmaticsc mentioned this pull request Nov 3, 2020

Extend CSP DSL to support both Content-Security-Policy and Content-Security-Policy-Report-Only headers #40525

Open

jrmhaig mentioned this pull request May 28, 2024

Add CSP mapping for 'wasm-unsafe-eval' #51934

Merged

4 tasks

Conversation

pixeltrix commented Nov 15, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeremy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pixeltrix commented Nov 16, 2017

Uh oh!

kaspth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dwightwatson commented Nov 27, 2017

Uh oh!

pixeltrix commented Nov 27, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dwightwatson commented Nov 27, 2017

Uh oh!

pixeltrix commented Nov 27, 2017

Uh oh!

pixeltrix commented Nov 27, 2017

Uh oh!

dwightwatson commented Nov 27, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pixeltrix commented Nov 27, 2017

Uh oh!

ryenski commented Nov 28, 2017

Uh oh!

pixeltrix commented Nov 28, 2017

Uh oh!

pixeltrix commented Nov 15, 2017 •

edited

Loading

pixeltrix commented Nov 27, 2017 •

edited

Loading

dwightwatson commented Nov 27, 2017 •

edited

Loading