Add support for CSP headers about nelmiosecuritybundle HOT 16 CLOSED

See https://www.owasp.org/index.php/List_of_useful_HTTP_headers for details

from nelmiosecuritybundle.

Would be cool to have a configured endpoint where the logging/reporting of CSP could post data.

from nelmiosecuritybundle.

Yup that would be good too.

from nelmiosecuritybundle.

@rickard2 wanna work on this? :)

from nelmiosecuritybundle.

@willdurand sure I would love to, how do we get started?

from nelmiosecuritybundle.

@rickard2 I guess we need to define how this can be configured, if it makes sense at all etc and then implement a new response listener.

from nelmiosecuritybundle.

I haven't had time to read the specification yet but a quick glance at http://www.html5rocks.com/en/tutorials/security/content-security-policy suggest something along the lines of:

 nelmio_security:
    csp:
        default: [ self, 'https://cdn.whatever.org' ] 
        img: [ self, 'https://img.whatever.org' ]

Then there's also some special keywords you can use, like self, none, unsafe-eval, unsafe-inline. These need to be quoted in the header and requires some special handling.

Also, the spec seems to allow both 'self' and self:

These keywords require single-quotes. script-src 'self' authorizes the execution of JavaScript from the current host. script-src self allows JavaScript from a server named “self” (and not from the current host), which probably isn’t what you meant.

I'm not sure how you can allow both self as a keyword and self as a hostname in the configuration.

from nelmiosecuritybundle.

I wouldn't bother allowing self as a hostname really. It makes sense that the spec describes it for completeness, but I don't think we have to care in this context. I would treat self as 'self' always quoted. Same for the other keywords.

from nelmiosecuritybundle.

Another question is whether we want to allow configuring CSP per URL pattern (like many of the other features of this bundle) or if we should just allow global settings for the application. I guess having the possibility to only do it in one part of the app makes sense.

from nelmiosecuritybundle.

I just threw something together to see if I'm approaching this the right way: rickard2@40fb8b4

Any early feedback?

from nelmiosecuritybundle.

It's a good start but only outputs the default-src for now right? I'm wondering if the headers shouldn't be pre-computed when the container is built so that the listener only gets a string and adds the string straight to the response, no looping and keyword quoting and such. You could still have some helper class to build the header from a configuration, but just call it once and not at every request.

from nelmiosecuritybundle.

Yes, just implemented default-src right now to try out the structure.

That sounds like a better approach, I will change the EventListener to just accept the values of default-src, img-src and so on.. The configuration part of SF2 isn't really my strong suit..

from nelmiosecuritybundle.

I think I've got all the regular directives working now in rickard2@f96ac75

Will look into reporting URI next. Also found a couple of interesting bits in the spec which we should think about supporting:

• Sandboxing: http://www.w3.org/TR/CSP/#sandbox-optional
• Reporting only: http://www.w3.org/TR/CSP/#content-security-policy-report-only-header-field (which apparently is a different header)

Then there's also the question of non standard variants of the header, like X-Content-Security-Policy (Firefox: https://developer.mozilla.org/en-US/docs/Security/CSP/Using_Content_Security_Policy) and X-Webkit-CSP (Older webkit, probably safari: http://blog.chromium.org/2011/06/new-chromium-security-features-june.html)

from nelmiosecuritybundle.

Regarding "reporting only" this could be a bool flag besides the default/img/... configs I imagine.

Sandboxing I'm not sure what it is, the spec isn't extremely explanatory from a quick scan.

As for the legacy non-standard headers, I would say send them for now, and we'll remove them in a future release when it's reasonable to do so?

from nelmiosecuritybundle.

I didn't quite get the sandboxing part either, let's leave that out for now.

I'll try to put some time into the configuration part later this week

from nelmiosecuritybundle.

Any reason why the PR hasn't been merged yet?

from nelmiosecuritybundle.