do not dedupe alternate schema source expresions

[keithamus]

All PRs:

• Has tests
• Documentation updated N/A

Adding a new header

Generally, adding a new header is always OK.

• Is the header supported by any user agent? If so, which? N/A
• What does it do? N/A
• What are the valid values for the header? N/A
• Where does the specification live? N/A

Adding a new CSP directive

• Is the directive supported by any user agent? If so, which? N/A
• What does it do? N/A
• What are the valid values for the directive? N/A

This correct a bug in the dedup_source_list function, which causes sources with different protocols to be removed, which breaks possible CSP as headers as the spec only allows for current protocol for schemaless source expressions.

Consider the following connect-src: *.example.com wss://*.example.com. This effectively allows for http and websocket connections. The current version of secure_headers will minify this to be connect-src: *.example.com which only allows for http connections, disallowing websocket connections.

The fix here is to check that the schemes match for wildcard sources, using URI(source).scheme. For a scheme-less URI like *.example.com, the URI will come back with a scheme of nil, which is fine. There is a step before dedup_source_list which strips known schemes like http/https.

[JackMc]

Hey! Thanks for the contribution. I'm unable to reproduce this behaviour. I set up a standard Rails 7 app with a scaffolded resource named posts and added the following SecureHeaders initializer:

SecureHeaders::Configuration.default do |config|
  config.csp = {
    default_src: %w(* 'unsafe-inline' blob:),
    script_src: %w('self' blob: 'unsafe-inline' data:),
    connect_src: %w('self' *.example.com wss://*.example.com),
  }
end

And the following inline script in the resources #index page:

<script>
  fetch('https://example.com');
</script>

<script>
  webSocket = new WebSocket('wss://example.com');
</script>

The CSP returned from Secure Headers appears to be:

Content-Security-Policy: default-src * 'unsafe-inline' blob:; block-all-mixed-content; connect-src 'self' *.example.com wss://*.example.com; script-src 'self' blob: 'unsafe-inline' data:

And the WebSocket/fetch appear to succeed (insofar as they can on example.com).

Copying the test from spec/lib/secure_headers/headers/content_security_policy_spec.rb to master passes. Could you provide a failing test case? Happy to hop on a call and discuss if that's easier!

[JackMc]

On Slack, Keith and I determined that the bug occurs only with a combination of a non-wildcard wss:// URL and a wildcard schemaless URL. With some test changes plus the small nitpick about the source URL pattern I think we should be good to go!

[keithamus]

Thanks for discussing over Slack @JackMc! I've addressed both the badly written test and the precomputation of schemes.

[srt32]

@keithamus @JackMc are we cool to merge this change?

[JackMc]

I don't see any problem with it!

[srt32]

I don't have merge access. Could you click the button?