search

NatLibFi / Skosmos

Thesaurus and controlled vocabulary browser using SKOS and SPARQL
Other
229 stars 95 forks source link

In-line scripts are blocked when Content-Security-Policy headers are enforced by the web server #1180

Open solomchuk opened 3 years ago

solomchuk commented 3 years ago

At which URL did you encounter the problem?

Any Skosmos browser page will be affected by this.

What steps will reproduce the problem?

  1. Configure the web server to set Content-Security-Policy (CSP) headers, e.g. for Apache: Header set Content-Security-Policy "default-src 'self';"
  2. Start the web server and Skosmos browser
  3. Open any page served by the Skosmos browser

What is the expected output? What do you see instead?

Expected: All Skosmos page contents loading correctly. Observed: CSP is blocking all in-line scripts from loading. Alphabetical/Hierarchy navigation not loading consistently.

What browser did you use? (eg. Firefox, Chrome, Safari, Internet explorer)

Firefix 89.0.1 (64-bit).

Additional info

CSP is a useful security tool, especially for preventing some cross-site scripting (XSS) and injection attacks. CSP HTTP page headers allow for tight control of loading various resources (including JavaScript).

The script-src directive in a CSP header controls which scripts are allowed to load. E.g. Content-Security-Policy script-src 'self' allows loading of scripts from the same origin. However, with script-src enabled in-line scripts are blocked by default. There are three ways to allow in-line scripts with script-src:

  1. By providing a hash of your script block in the CSP HTTP response header.
  2. By providing a nonce value in the CSP HTTP response header.
  3. By setting script-src 'unsafe-inline', which allows all in-line scripts but completely disables the security benefits of CSP.

It would be useful to make Skosmos compatible with CSP by either not using in-line scripts altogether, or providing a nonce/hash in the response headers where such scripts are used. As things stand, it is not possible to use CSP against malicious XSS attacks without breaking something in Skosmos.

osma commented 3 years ago

Thank you for the issue report. It would be non-trivial to support CSP, because many inline <script> blocks are currently used and more can be added (and often are) by the administrator using .inc files such as footer.inc; this is typically used to add e.g. banners and analytics tracking.

Is CSP support a requirement for you @solomchuk ? Is this something you would be interested in working on and perhaps contributing?

solomchuk commented 3 years ago

Thank you for the response, @osma.

Our client performed a Qualys Web Application Vulnerability Scan on our instance of Skosmos, and a decent number of issues in the report are related to XSS and other vulnerabilities mitigated by CSP. The requirement we have is to implement a layer of protection against such attacks. CSP headers configured in the web server was the first, and easiest, solution I came across. Since this is currently not an option, we'll be looking at other potential solutions.

Unfortunately, I'm an integrator, not a web developer, so the type of contribution I could make is fairly limited. But I'll be happy to share any workarounds I may find to the security issues we found.