docassemble
docassemble copied to clipboard
jhpyle
CSP error when embedding interview into a div
When embedding docassemble into a div (via the js_target= parameter), and the website is behind a Content Security Policy, the browser (Chrome) is blocking parts of the returned JS script that refer to 'eval' function calls (which are called by daGlobalEval references).
Can you please advise if there is a fix or workaround that doesn't require setting 'unsafe-eval' as part of the CSP?
The docassemble application has a number of features that rely on JavaScript eval(). E.g., https://docassemble.org/docs/modifiers.html#script, https://docassemble.org/docs/functions.html#log, https://docassemble.org/docs/fields.html#js%20show%20if Each time the screen loads the server might provide additional JavaScript that needs to be evaluated.
I think cross-site embedding might be going obsolete anyway because browser developers consider it to be a form of "tracking" that the user needs to opt into.
I would suggest making the embedding non-cross-site by configuring the host web server to act as a reverse proxy for your docassemble server.
@jhpyle if it is embedded via a div and not an iframe, i'm wondering how is it a form of "cross-site embedding"? See https://developers.google.com/web/fundamentals/security/csp#eval_too for more information.
The way that docassemble currently works relies on cookies. Whether embedding happens with a <div> or an <iframe>, JavaScript in the browser is making HTTP requests with cookies to a server other than the one in the user's location bar, and the browsers will consider that to be unwanted tracking.
I am working on getting rid of the reliance on cookies for storing a session key, but even then I don't think I can get rid of the reliance on eval(), at least not without compromising existing features, like the ability to use Mako in js show if and script specifiers. I could be wrong, but it seems to me that the browsers don't have a problem with eval() if the JavaScript is coming from the same site, which is why I was suggesting using a reverse proxy.
eval is bad if it comes through from the same site, imagine a scenario where it might eval user content supplied from an interview answer - An attacker could easily run a script into your input field in order to perform a DOM Based XSS (cross site scripting) attack
https://book.hacktricks.xyz/pentesting-web/content-security-policy-csp-bypass#unsafe-eval includes a bunch of scenarios where unsafe-eval (and unsafe-inline) can be bad