Request for Security Improvment: The Content Security Policy (CSP) is not very effective.

[gni001]

Is your feature request related to a problem? Please describe. No - but it could be a Security Improvment. In our company we start to use MeshCentral. It is an excelent remote SW and we Thank you for it being an open-source project!

A security service provider is reporting that our MeshCentral could be improved in two areas. This is a short description from the report: ‘The Content Security Policy (CSP) is a recommended 'Defense-in-Depth' Ability that can minimize the risk of a successful 'Cross-Site-Scripting' attack. It is positive to note that the tested web application has a CSP in use. However, this is somewhat poorly configured and therefore ineffective.’ Technical Description For the tested application, the following CSP is activated in the HTTP response: ... Content-Security-Policy: default-src 'none'; font-src 'self'; script-src 'self' '**unsafe-inline**'; connect-src 'self' wss://ourCompany.com wss://ourCompany.com:443; img-src 'self' blob: data: data:; style-src 'self' '**unsafe-inline**'; frame-src 'self' blob: mcrouter:; media-src 'self'; form-action 'self'; manifest-src 'self' ... The ‘unsafe-inline’ directive at script-src bypasses the XSS protection of the CSP. The script code should be outsourced to external .js files and the respective sources should instead be released. The ‘unsafe-inline’ directive at style-src allows so-called Cross-Site-Styling attacks, in which the stylesheet is manipulated. Thus, UI elements can be hidden, texts can be manipulated, or even a keylogger can be integrated into the page. ...

Describe the solution you'd like The Solution would be: usig 'Nonces' or 'Hashes'. Can you check whether the 'unsafe-inline' directives can be secured with the use of ‘Nonces’ or ‘Hashes’ and if possible: implement them. Many Thanks in Advance. Andreas

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context

[Ylianst]

Ha yes, I agree with this. Previous audits I have done have indicated that a fully locked down CSP policy would be best (and I agree), however, it would be a lot of work to implement in practice. It's not a question of just changing the CSP flags, a strict CSP policy does not allow any JavaScript embedded within HTML so the change would be massive. One idea at some point would be to look at re-doing the client page using a framework like ReactJS, VuJS or something else. So yes, I completely agree with your security review and the defense in depth.

If you have an suggested way to implement this, I would be interested. If there is some tool that auto fixes the pages, that would be wonderful. We are looking at many hundred hours of work if done manually.

[gni001]

Hi Ylian, Thanks for your Response. It seems, the effort to comply with strict CSP exceeds the benefits… Unfortunately, I haven’t found a tool that does this.  I’ll look into whether I could program something like that - depending on effort Yes, there are at least two approaches for embedding JavaScript safely inside HTML as suggested by our security service provider (see copilot’s translation attached). ·        CSP with ‘Hashes’ - for static content only ·        CSP with ‘Nonces’ could be used by dynamic content However, I haven’t tested this on a live system yet. I also haven’t checked how it is interpreted by automated CSP evaluators (see References: 5, 7 and 8). Please kindly check – is this a more effective way to go – or this require similar effort as re-doing the client page as you mention before? Many Thanks BR / Grüße Andreas PS: Here some used references: [4] Report URI. Generate your Content Security Policy [5] Report URI. Analyse your CSP [6] Can I use. Content Security Policy Level 2 [7] Mozilla Observatory[8] Google CSP EvaluatorMessage ID: @.***>