THREESCALE- 6512: Allow custom CSP

[jlledom]

What this PR does / why we need it:

We previously added an all-allowed policy for convenience (#3861), but we provided no way to configure any other CSP policy. This PR accepts a new config file under config/content_security_policy.yml where porta loads its CSP policy from. Example:

  admin_portal_policy:
    default_src: ["'self'"]
    script_src: ["'self'", "'unsafe-inline'", "'unsafe-eval'", "<%= ENV['RAILS_ASSET_HOST'] %>"]
    style_src: ["'self'", "'unsafe-inline'", "<%= ENV['RAILS_ASSET_HOST'] %>"]
    font_src: ["'self'", "data:", "<%= ENV['RAILS_ASSET_HOST'] %>"]
    img_src: ["'self'", "data:", "blob:", "https:"]
    connect_src: ["'self'"]
    frame_src: ["'self'"]
    frame_ancestors: ["'none'"]
    object_src: ["'none'"]
    base_uri: ["'self'"]

The PR consists basically in four changes:

• Read the new config file from application.rb
• New CSP config loader classes, for convenience.
• Update the initializer to get the global config from the CSP config class.
• New middleware to set a different policy for the developer portal.

If no CSP config file, it will fall back to the previous all-allowed policy. When present, it will apply admin_portal_policy To master and provider portals, and developer_portal_policy to developer portals.

In fact, admin_portal_policy is set on rails as global policy, so if no developer_portal_policy is provided, admin portal CSP will be applied to dev portal as well.

By default, I'm setting the all-allowed policy to dev portal anyway, because we can't know what clients will publish there. About admin portal, I'm setting a more restrictive defaults that would be valid for the whole portal, tests pass, however I might have missed something, let's see.

By default the CSP policy is enabled in all environments, including development and test, the reason is for future developments that could introduce new CSP violations to be revealed before they reach production.

Additional comments

At the beginning I discarded allowing different CSP policy for admin and developer portal, because this CSP cusomization only makes sense for Dev portal actually, since clients can't decide the contents of the admin portal, other than allowing the CDN url. However, if we only have one global policy, whatever clients set for their developer portals would affect also the admin portal, over which they have no control. So I finally opted for allowing different policies.

There are a few features I discarded for different reasons:

1. Add support for new report-to directive

We support report-uri (docs), which is marked as deprecated, however, its replacement report-to is not supported by rails yet (docs only mention report_uri, also, the :report_to method is not defined in the class).

The CSP directive and the required HTTP header are also not widely supported for all browsers yet, e.g. not supported at all in Firefox.

I could add a small implementation, via middleware, but I think it's better to just use what rails provide today, that way the code will be easier to maintain.

2. Use secure_headers gem rather than Rails builtin support.

We are currently depending on the secure_headers gem. And that gem allows to add support for CSP. However, its CSP support doesn't offer any advantage over rails builtin support, so I opted for Rails, for better maintainability. Also, we would need to update the gem to a newer major version in order to get the same features rails provides.

Which issue(s) this PR fixes

https://issues.redhat.com/browse/THREESCALE-6512

Verification steps

1. Try different policies, verify the Content-Security-Policy HTTP header is actually set to what is configured in the yaml file.
2. In the yaml file, set enabled to false. The CSP header should contain the old all-allowed policy.
3. Remove the yaml file. The CSP header should contain the old all-allowed policy.

[jlledom]

@mayorova yes to all: 04a1f96

[mayorova]

It's a bit strange that in the default config it's enabled, and in each environment, which inherits from it, it's also explicitly set as enabled: true :)

[mayorova]

Also, I am wondering... Could it make sense to have enabled and report_only at each level (admin vs dev portal) rather than globally? Because the customer might desire to only override the configs for e.g. dev portal, and not admin portal?

[jlledom]

Good idea, I did it here: a0de8cd

[mayorova]

I actually meant something like:

base: &default
  admin_portal:
    enabled: true
    report_only: false
    policy:
      default_src: ["'self'"]
      # others
  developer_portal:
    enabled: true
    report_only: false
    policy:
      default_src: [ "*", "data:", "mediastream:", "blob:", "filesystem:", "ws:", "wss:", "'unsafe-eval'", "'unsafe-inline'" ]

WDYT?

[jlledom]

WDYT?

No objections: 07418e8

[mayorova]

It's a bit complicated for me... because I have no idea how this is supposed to work. But it seems that most of the logic is similar to what https://github.com/rails/rails/blob/v7.1.5.2/actionpack/lib/action_dispatch/http/content_security_policy.rb#L35 does.

I guess it's fine... It's unfortunate though that we (apparently) cannot reuse the existing logic.

[jlledom]

Well, basically, I created this class and added it to the developer portal middleware stack.

• On startup, a new instance will be initialized.
• On every request, the call method will be called.

Our call method is called by the previous middleware in the stack. By calling @app.call(env) we yield control to the next middleware in the stack, and eventually to the controller.

This class basically generates the headers once on startup and then adds them to each request. We can't reuse the existing middleware because that one takes the CSP policy from the Rails global CSP configuration, but we need to take it from our yaml file.

However, the Rails CSP middleware is in fact installed also in the stack, so we are calling it anyway, that's why we have this snippet:

unless request.format.html?
  request.content_security_policy = false
  return @app.call(env)
end

When the request is HTML, we handle it; when it's not, we don't, and ensure the rails middlware doesn't handle it neither.

[jlledom]

• Admin portal: Yaml -> Rails Global CSP config -> Rails CSP middleware
• Dev portal: Yaml -> Our dev portal CSP middleware

[akostadinov]

I'm wondering, does this need to be per instance or per tenant? I assume the admin/master portals need to be per instance because we don't have custom stuff in there. For dev portals, it would make some sense to be individual. Just asking whether this makes practical sense. It will be a little more user friendly if configured from UI but given it will probably rarely be used, perhaps doesn't make much practical sense... thinking out loud.

[jlledom]

I'm wondering, does this need to be per instance or per tenant?

Yeah it would be good to be per tenant, specially the dev portal ones. But that would require more effort: Adding columns to the settings table, or maybe a new table; adapt models, creating the API endpoints or UI + Controllers... Do you want to create an issue?

[akostadinov]

Do you want to create an issue?

Only if you think that the benefit will outweigh the effort. Otherwise we can go like this and see if requests come.

[jlledom]

Do you want to create an issue?

Only if you think that the benefit will outweigh the effort. Otherwise we can go like this and see if requests come.

It would be useful for SaaS, of course. Not sure about On premises. Do on premises clients have more than one tenant usually?

I wouldn't do it only for SaaS