Enhance webknossos security

[daniel-wer]

In my recent talk I've pointed out several issues and ways to enhance webknossos security, which should be addressed.

• [x] Fix popover XSS in task overview
• [x] Fix possible XSS caused by <%= that is being used in Backbone templates
• [x] Set security.javascriptEnabled to False in the Mongo config to prevent possible NoSql injections
• [ ] Restrict lifetime of Play Session IDs (https://www.playframework.com/documentation/2.5.x/ScalaSessionFlash) → we don’t store anything in the sessions, cookie/auth token lifetime is separate
• ~[ ] Adjust Same-Origin Policy (CORS headers) for Datastore to no longer be "*"~ → we use token-based authentication for datastore, no cookies
• [x] Include X-Frame-Options: DENY Cookie to prevent Click-Jacking
• [ ] Investigate and determine a reasonable Content-Security-Policy to prevent possible future XSS issues

Log Time

[jfrohnhofen]

Probably related: On prod master, the dataset description now contain html as text, that is no longer evaluated:

[daniel-wer]

That's not a bug, that's a feature :D Of course we can allow html in the dataset description if it's needed, I wasn't aware of someone using it and couldn't find a dataset on master that has an html description either (the one in the screenshot no longer has one).

[normanrz]

Can we allow "safe" HTML there? Perhaps Markdown?

[fm3]

@daniel-wer are the remaining items here still open? Is any of that easily done? Or can we possibly close this issue?

[daniel-wer]

(1)

Adjust Same-Origin Policy (CORS headers) for Datastore to no longer be "*"

As we're using a GET token to authenticate requests to the datastore (not a Cookie which would be sent automatically by the browser), the SOP is not that important. If a user visits a malicious website which makes a request to the datastore, the request will be unauthenticated and not return anything.

(2)

Include X-Frame-Options: DENY Cookie to prevent Click-Jacking

I would do that, otherwise webKnossos will be open to click jacking attacks. I've prepared a quick demo for that, if you're logged in to webknossos in another tab, a malicious website could do this: https://jsfiddle.net/t6werxs7/

(3)

Investigate and determine a reasonable Content-Security-Policy to prevent possible future XSS issues

As we're using react to render almost everything, which takes care of escaping user supplied data, this does not have high priority. We're not using dangerouslySetInnerHTML, user supplied href prop values or HTML enabled markdown - all things that could lead to XSS even when using React - so I would argue we're pretty safe. It would nevertheless be worthwhile to investigate this as part of another issue and proactively create a Content-Security-Policy (https://content-security-policy.com/) to avoid future possible XSS vectors.

Summarizing, (1) is not needed, (2) should be easily done, (3) worthwhile but low-pri, I'll create a separate issue for that.

[fm3]

Thanks for investigating! I’ll look into (2) then, and close this issue when it’s done. For reference: https://www.playframework.com/documentation/2.4.x/SecurityHeaders

[daniel-wer]

Great, I created issue #3085 to track progress regarding the CSP.