secure_headers icon indicating copy to clipboard operation
secure_headers copied to clipboard

CSP sources are incorrectly removed when both wildcards and schemes are present

Open tessereth opened this issue 7 years ago • 5 comments

When I have the following as part of my csp header config:

  config.csp = {
    frame_ancestors: %w[*.foo.com http://www.foo.com],
    preserve_schemes: true,
    ...
  }

and I'm serving my frame over https to be embedded on http://www.foo.com, the http://www.foo.com is required but is being removed by minify_source_list

Expected outcome

I expect to have frame-ancestors *.foo.com http://www.foo.com in my CSP header

Actual outcome

The CSP header had only frame-ancestors *.foo.com

Config

SecureHeaders::Configuration.default do |config|
  config.csp = {
    default_src: %w['self'],
    script_src: %w['self'],
    frame_ancestors: %w[*.foo.com http://www.foo.com],
    preserve_schemes: true
  }
end

Generated headers

Content-Security-Policy: default-src 'self'; frame-ancestors *.foo.com; script-src 'self'

tessereth avatar Nov 29 '17 00:11 tessereth

I think this is correct however I'll need to re-read the match source expression another 10 times to let it sync in and work out whether this is valid policy or not. There is also a section on frame ancestors multiple source values which you might want to keep in mind.

Out of curiosity, have you tried frame_ancestors: %w[https://*.foo.com http://www.foo.com]? Veryyy sketchy and ill advised but might help here.

jacobbednarz avatar Nov 29 '17 00:11 jacobbednarz

That is indeed the correct response to reading the match source expression document 😜 . As for the other one, I hadn't seen it so thanks. We already do something along those lines but we can still end up with more than one entry with out current solution.

I can definitely work around this if I need to (by only putting one entry in the list or adding the https prefix, which does work thanks) but I figured if it's a bug here then it would make sense to fix it here. I'm sure someone else will run into it at some stage.

tessereth avatar Nov 29 '17 01:11 tessereth

Personally, I'd recommend always being specific about the protocol to avoid DDoSing your reporting reporting endpoint due to broken Safari.

jacobbednarz avatar Nov 29 '17 03:11 jacobbednarz

Personally, I'd recommend always being specific about the protocol

secure_headers is pretty aggressive about stripping protocols. GitHub doesn't ingest reports, is this causing an issue for others or does the current behavior work well enough?

oreoshake avatar Nov 29 '17 18:11 oreoshake

I'll be able to give you an idea very soon 😄 Right now I'm just wrapping up some infrastructure testing combined with scaling out https://github.com/jacobbednarz/go-csp-collector and we'll be ingesting all of ours to perform analysis. I too would like to drop the protocols however it still looks like the safari bug is a thing for us but easy enough to work around.

jacobbednarz avatar Nov 29 '17 20:11 jacobbednarz