guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zer0Cool <>
Subject Re: Nginx Content_Security_Policy?
Date Mon, 06 May 2019 17:50:14 GMT
As per vnick's suggestion I used the dev tools in the browser and was able to
at least get some information.

I have adjusted the CSP line to the following:

add_header Content-Security-Policy "default-src 'self' 'unsafe-inline';
script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'sef' data:;"

This seems to load the login screen without error and allows logging in. I
can then navigate around in settings etc. I am not seeing any further errors
in console (of the dev tools) related to CSP, but I have yet to test actual
connections (as a separate matter I am having issues with Win 10 accepting
RDP connections).

I am by no means suggesting at this stage that anyone else use the above
settings in production. Just that its a starting point for testing how tight
the policy can get before breaking things.

Without the 'unsafe-inline' in default-src the login page would look normal
but not login and referenced line 1 of the html of the page which was the
"!DOCTYPE htmL" line. Without 'unsfae-inline' and 'unsafe-eval' I would get
a bunch of errors on the login page (in the web dev console) like:

EvalError: "Call to Function() blocked by CSP" (compile
Content Security Policy: the pages settings blocked the loading of a
resource at eval/inline ("script-src"/"default-src")
Error: "[$interpolate:interr] https://errors.angularjs..."

I am starting to wonder if the inclusion of the "unsafe" parameters makes it
worth using CSP at all. Its entirely possible to refine the scope of CSP to
the point everything works only to realize it provides little to no benefit
once implemented.

Any input would be great. Thanks

Sent from:

View raw message