Feature #21418
openUse Content-Security-Policy header to allow inline loading of files from keep-web even with TrustAllContent: false
Description
User wants to be able to load HTML report files inline from keep-web without requiring wildcard domains, but minimizing XSS risks that come with the current TrustAllContent: true
behavior.
I think we could use the Content-Security-Policy header:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
One way this can work is limiting what URLs the page can access using default-src
:
Content-Security-Policy: default-src https://collections.zzzzz.arvadosapi.com/c=zzzzz-4zz18-of3r1p2kc0js187/ https://collections.zzzzz.arvadosapi.com/by_id/zzzzz-4zz18-of3r1p2kc0js187/
This would limit the script so it could only access paths inside the collection.
We would probably want to combine this with a CORS preflight that limits HTTP methods to GET.
Therefore: if the script can only read files from the collection that it came from, and it can't connect anywhere else, and it can't write back to the collection, I think that would meaningfully limit malicious script behavior. In this case, it might be able to read the user's token, but it wouldn't be able to send it anywhere else.
However, limiting what they can read would mean these pages would have less capabilities -- they would not be able to fetch resources from other places, such as a CDN copy of bootstrap.
Another possiblity is the sandbox
directive:
Content-Security-Policy: sandbox allow-scripts;
I believe this would prevent the page from seeing cookies and local storage, which might be more like what we want -- however this might prevent the page from loading other resources from the collection, because it wouldn't get the cookie with the access token.
Updated by Peter Amstutz 10 months ago
Since I've been studying it let me outline the current security policy around inline document in keep-web:
With multi-domain: A cookie containing the API token is set on the domain for that particular collection. It has the HttpOnly
directive, which means the cookie is not visible to javascript. As a result, code on the page has authenticated access only to collection contents. Code on the page can still access other public resources, but won't inherit any credentials, because of the domain boundary.
With single domain: The cookie is still set with HttpOnly
(I assume) and so the cookie is still not visible to javascript. However, because everything is hosted from a single domain, javascript code can access any other collection that is the user can access, and could use that to read sensitive data from a collection and send it to a third party. As a result, the default policy (unless TrustAllContent: true
is set) is to disallow inline loading of documents by specifying attachment=download.
Setting Content-Security-Policy would limit the page to loading resources from the collection itself. However this is more limiting than the multi-domain case, because it would also be unable to load public resources from other locations. I don't think it is possible to provide a Content-Security-Policy that can limit loading certain paths on a specific domain while still allowing other domains.