Working content security policy for Phoenix channels?

Phoenix Forum Questions / Help
, ,
1

Hi,

I use sobelow to highlight potential security issues, and the latest version has started warning if no content-security-policy header is set. I fixed that by adding a custom header:

@csp "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval'"

pipeline :browser do
  # ...
  plug :put_secure_browser_headers, %{"content-security-policy" => @csp}
  # ...

However, this has stopped channels from working. I’ve tried adding various versions of ws://localhost:4000 and the like, but with no success.

Does anyone have a working CSP header for use with channels?

For bonus points, what’s the best way to get the hostname to use in the policy, assuming it needs to be different in production? I could just set a config value in the environment, but is it already available somewhere?

Thanks!

Kerry

1 Like
2

You can pull this information from the conn. There may be a better way to do this… for example, there is no check to see if the endpoint is/should be wss.

def ws_url(conn) do
  endpoint = Phoenix.Controller.endpoint_module(conn)
  
  %{endpoint.struct_url | scheme: "ws"} |> URI.to_string()
end

Have you tried connect-src? Apparently you must define it for each scheme you use. More information here.

Here’s what it might look like:

@csp "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src ws://localhost:4000/"

I tried testing this, but I can’t tell if it works or not.

1 Like
3

what @ryh said… just remember wss in production:)

1 Like
4

Thanks! The root of my problem was putting the ws:// URI in quotes, but the struct_url thing was really helpful too. FWIW I ended up with this:

defmodule MyAppWeb.CSPHeader do
  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    put_resp_header conn, "content-security-policy", csp(conn)
  end

  defp csp(conn) do
    "default-src 'self'; \
    connect-src 'self' #{ws_url conn} #{ws_url conn, "wss"}; \
    script-src 'self' 'unsafe-inline' 'unsafe-eval'; \
    style-src 'self' 'unsafe-inline' 'unsafe-eval'"
  end

  defp ws_url(conn, protocol \\ "ws") do
    endpoint = Phoenix.Controller.endpoint_module(conn)
    %{endpoint.struct_url | scheme: protocol} |> URI.to_string()
  end
end
4 Likes
5

This was really helpful Kerry, thank you. With respect to the Sobelow warnings, did you just suppress this warning because the plug you wrote covers it? I’m able to use your plug to add a content-security-policy, but it does not pass Sobelow’s test.

6

Yes, I’ve just looked at my sobelow config, and I’m ignoring Config.CSP.

7

Just wanted to comment on this, if someone else stumbles across this thread looking for help on fixing sobelow warning about config.CSP even though you’re setting it:

$ mix sobelow -d Config.CSP

# ...

Missing Content-Security-Policy is flagged by sobelow when a pipeline
implements the :put_secure_browser_headers plug, but does not provide a
Content-Security-Policy header in the custom headers map.

# ...

This is referring to this:
https://hexdocs.pm/phoenix/Phoenix.Controller.html#put_secure_browser_headers/2

You can obviously set headers in different places, so sobelow is just looking that if you have a pipeline that calls plug :put_secure_browser_headers in your Router, that you also include a map with %{"Content-Security-Policy" => "..."} so it should look like this:

plug :put_secure_browser_headers, %{"Content-Security-Policy" => "..."}
7 Likes
8

@iautom8things thanks for adding your reply! If one were to use the map like you suggested, what would folks suggest the contents to be?

When it comes to security I always defer to public and discussed solutions, since incorrect in-house solutions are usually the ones that end up failing and causing vulnerabilities.

Thanks for discussing these things in public, the community always benefits from these discussions.

More info on why how an incorrect implementation can bite you hard: https://www.netsparker.com/blog/web-security/negative-impact-incorrect-csp-implementations/

Edit: I created this issue: https://github.com/nccgroup/sobelow/issues/61