Add support for Content Security Policy header

[ctrlaltca]

Content Security Policy (CSP) is a security header better documented at https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
In order to use it with a Prado app it's currently necessary to specify unsafe-inline to let the browser load script and styles that Prado places inline inside the page.
Three possible alternatives:

1. move every script/style block to an external file
2. calculate an hash for each script/style block and add it to the header
3. create a per-response nonce value and add it to each script/style block.

The first alternative is probably the best generic solution, but in order to implement this we would need to create a few new javascript files for each request (eg. for beginScripts and endScripts registered by TClientScripManager), handle their lifecycle (aka delete them after load) and ensure they can't be reached by other clients (they may contain private data).

The second alternative requires Prado to calculate the base64(sha256($content)) for every script and style block, making all of them available to be added to the CSP header. Additional integrity attributes (content hashes) must be present on external scripts. This is solution meant to be used for static scripts, eg. while importing a common library from a CDN.

The third alternative requires Prado to generate a nonce (that is a random string) to be added to the CSP header and then add a "nonce" attribute on every script/style block.

We should possibly move whatever is possible to external scripts (solution 1), create some hooks to permit the generation of hashes for script/style blocks (solution 2) and add support for optional nonces wherever we output a script/style blocks (solution 3).

Once this is in place, a new module can be created taking care of:

• collect the CSP configuration
• output the CSP header
• implement solution 2 (hashes)
• implement solution 3 (nonces)

[ganiuszka]

Hello @ctrlaltca,

This is fantastic news! Great to hear that you want to add support for this header.

Thanks for describing the ideas for implementation. I am not familiar too much with this header, but below I added my generic comments for that. I am not sure if they are fully correct, but you will see.

The first alternative is probably the best generic solution, but in order to implement this we would need to create a few new javascript files for each request (eg. for beginScripts and endScripts registered by TClientScripManager), handle their lifecycle (aka delete them after load) and ensure they can't be reached by other clients (they may contain private data).

I am not sure if I correctly understand this part. Do you mean dynamically creating js/css files on the file system in available publicly writeable path? If yes, here are my thoughts about it:

1. Deleting files can be not easy because js/css need to be used on client side and server does not know when exactly web browser will load them.

2. I think this is very important what you wrote that this code can contain private data. Currently some of this data can available only in restricted application areas. With using this part in public external scripts, this data will be moved outisde this restricted access. In my opinion, even if scripts will be protected by strong random string, this can be risky due to e.g. brute force attacks. Also worth to mention that code blocks usually are not strongly cached by the web browser (HTTP GET request) while external js/css are cached. So, even if somebody will log out from application, the code will be in web browser. The caching can also depend on the server (HTTP caching headers) and the client (various web browsers).

3. Probably the execution order can be a problem because some code requires to be executed in exact place. Moving blocks to file can (but not have to, or course) disturb this execution.

We should possibly move whatever is possible to external scripts (solution 1), create some hooks to permit the generation of hashes for script/style blocks (solution 2) and add support for optional nonces wherever we output a script/style blocks (solution 3).

I can be wrong but I think that using integrity hash or nonce can be much easier than moving code to the external scripts. On the implementation side, for example the Prado control to include js/css code blocks could have a new boolean parameter to enable/disable computing the nonce or integrity hash.

Thanks for your work on this module. I wish you good luck with that. I don't know Prado on the developer level, but if I can help somehow in this module, please let me know.

Best regards,
Marcin Haba (gani)