Project

General

Profile

Feature #21418

Updated by Peter Amstutz 4 months ago

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@: 

 <pre> 
 Content-Security-Policy: default-src https://collections.zzzzz.arvadosapi.com/c=zzzzz-4zz18-of3r1p2kc0js187/ https://collections.zzzzz.arvadosapi.com/by_id/zzzzz-4zz18-of3r1p2kc0js187/  
 </pre> 

 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: 

 <pre> 
 Content-Security-Policy: sandbox allow-scripts; 
 </pre> 

 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. 

Back