Add support for Content-Security-Policy

[SamMousa]

We should add advanced support for Content-Security-Policy directives:

• Sign inline scripts using a hash.
• Only allow scripts that are included via registerJs, registerJsFile.
• Research what else we should support (CSP has options for framing as well as font loading).
• Support CSP for asset bundles

[samdark]

Any good reading on the subject?

[terabytesoftw]

I think it could be done in two ways via .htaccess and via Html :: tag ('meta')

[SamMousa]

https://websec.be/blog/cspstrictdynamic/

@terabytesoftw as a PHP framework .htaccess is not part of our stack.
CSP can be set via Meta tag and via headers.

[samdark]

@SamMousa I've checked it. Seems what's proposed with hashes still require extensive fallback usage. While hashes could be automated, I'm not sure about fallback.

If it could be done in a universal way, I am all for implementing it as part of assets concept.

[terabytesoftw]

in Yiisoft/Web in SapiEmiter.php in emit you can add:

$response = $response
    ->withHeader('Access-Control-Allow-Credentials', 'true')

and the remaining headers.

[samdark]

No, that is not the place to do it. SapiEmitter is just "echoing" what is contained in the response object as is. If you need extra headers, these should be added in a middleware.

[SamMousa]

Since this is the view component, would it make sense to always use a meta tag?
(That way we can keep the whole implementation local to view rendering)

Regarding script src verification, we could use a random nonce for every request; this would be really simple to implement.

[SamMousa]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

[samdark]

Since this is the view component, would it make sense to always use a meta tag?
(That way we can keep the whole implementation local to view rendering)

OK.

Regarding script src verification, we could use a random nonce for every request; this would be really simple to implement.

Fine.

[roxblnfk]

We have the ForceSecureConnection middleware with CSP policy support

[samdark]

@roxblnfk that doesn't include external file hashes.

[roxblnfk]

@roxblnfk that doesn't include external file hashes.

yes.
more precisely, you can define them there, but you will not be able to do this, because middleware is preconfigurable.

[SamMousa]

We have the ForceSecureConnection middleware with CSP policy support

To be honest, looking at the code in ForceSecureConnection, to me it seems like it is already taking on too much responsibility.

The class header Redirects insecure requests from HTTP to HTTPS, and adds headers necessary to enhance security policy. already hints at this.

Why not have a trivial RedirectToHTTPS middleware, that does exactly what it says and only that?

Furthermore, an HSTS header is added to normal HTTP requests, but that will always be ignored: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

For me CSP is a subject totally unrelated to HTTPS redirects and HSTS headers...

Since the CSP support that would best fit the framework is a dynamically generated one, it makes more sense to have a middleware later in the chain that gathers (or receives) parts from application services (like the view).

Since at the end of the request we know which inline and external scripts we have etc we can then decide calculate the final CSP header.

[roxblnfk]

We have the ForceSecureConnection middleware with CSP policy support

This is just notice, not solution.

The ForceSecureConnection middleware was created without considering this issue and only for general CSP rules like this.

If we will create a detailed solution with CSP, taking into account assets and so on, it will be cool. Then it will be possible to remove unnecessary responsibility from this middleware.