[ad_1]
Posted by David Dworken, Info Safety Engineer, Google Safety Staff
Many net functions have to show user-controlled content material. This may be so simple as serving user-uploaded pictures (e.g. profile images), or as complicated as rendering user-controlled HTML (e.g. an internet improvement tutorial). This has at all times been tough to do securely, so we’ve labored to seek out straightforward, however safe options that may be utilized to most forms of net functions.
The traditional resolution for securely serving user-controlled content material is to make use of what are referred to as “sandbox domains”. The fundamental thought is that in case your software’s major area is instance.com, you might serve all untrusted content material on exampleusercontent.com. Since these two domains are cross-site, any malicious content material on exampleusercontent.com can’t affect instance.com.
This method can be utilized to soundly serve every kind of untrusted content material together with pictures, downloads, and HTML. Whereas it could not look like it’s obligatory to make use of this for pictures or downloads, doing so helps keep away from dangers from content material sniffing, particularly in legacy browsers.
Sandbox domains are broadly used throughout the trade and have labored properly for a very long time. However, they’ve two main downsides:
Functions usually want to limit content material entry to a single consumer, which requires implementing authentication and authorization. Since sandbox domains purposefully don’t share cookies with the primary software area, that is very tough to do securely. To assist authentication, websites both should depend on functionality URLs, or they should set separate authentication cookies for the sandbox area. This second technique is very problematic within the fashionable net the place many browsers limit cross-site cookies by default.
Whereas consumer content material is remoted from the primary web site, it isn’t remoted from different consumer content material. This creates the chance of malicious consumer content material attacking different knowledge on the sandbox area (e.g. by way of studying same-origin knowledge).
Additionally it is value noting that sandbox domains assist mitigate phishing dangers since assets are clearly segmented onto an remoted area.
Over time the online has advanced, and there are actually simpler, safer methods to serve untrusted content material. There are numerous completely different approaches right here, so we’ll define two options which might be at the moment in large use at Google.
Method 1: Serving Inactive Consumer Content material
If a web site solely must serve inactive consumer content material (i.e. content material that’s not HTML/JS, for instance pictures and downloads), this will now be safely executed with out an remoted sandbox area. There are two key steps:
All the time set the Content material-Kind header to a widely known MIME sort that’s supported by all browsers and assured to not include energetic content material (when doubtful, software/octet-stream is a protected selection).
As well as, at all times set the under response headers to make sure that the browser totally isolates the response.
Response Header
Objective
X-Content material-Kind-Choices: nosniff
Prevents content material sniffing
Content material-Disposition: attachment; filename=”obtain”
Triggers a obtain moderately than rendering
Content material-Safety-Coverage: sandbox
Sandboxes the content material as if it was served on a separate area
Content material-Safety-Coverage: default-src ‘none’
Disables JS execution (and inclusion of any subresources)
Cross-Origin-Useful resource-Coverage: same-site
Prevents the web page from being included cross-site
This mix of headers ensures that the response can solely be loaded as a subresource by your software, or downloaded as a file by the consumer. Moreover, the headers present a number of layers of safety towards browser bugs via the CSP sandbox header and the default-src restriction. Total, the setup outlined above offers a excessive diploma of confidence that responses served on this method can’t result in injection or isolation vulnerabilities.
Protection In Depth
Whereas the above resolution represents a typically enough protection towards XSS, there are a variety of further hardening measures you could apply to supply further layers of safety:
Set a X-Content material-Safety-Coverage: sandbox header for compatibility with IE11
Set a Content material-Safety-Coverage: frame-ancestors ‘none’ header to dam the endpoint from being embedded
Sandbox consumer content material on an remoted subdomain by:
Serving consumer content material on an remoted subdomain (e.g. Google makes use of domains equivalent to product.usercontent.google.com)
Set Cross-Origin-Opener-Coverage: same-origin and Cross-Origin-Embedder-Coverage: require-corp to allow cross-origin isolation
Method 2: Serving Energetic Consumer Content material
Safely serving energetic content material (e.g. HTML or SVG pictures) can be executed with out the weaknesses of the traditional sandbox area method.
The best choice is to reap the benefits of the Content material-Safety-Coverage: sandbox header to inform the browser to isolate the response. Whereas not all net browsers at the moment implement course of isolation for sandbox paperwork, ongoing refinements to browser course of fashions are seemingly to enhance the separation of sandboxed content material from embedding functions. If SpectreJS and renderer compromise assaults are outdoors of your menace mannequin, then utilizing CSP sandbox is probably going a enough resolution.
At Google, we’ve developed an answer that may totally isolate untrusted energetic content material by modernizing the idea of sandbox domains. The core thought is to:
Create a brand new sandbox area that’s added to the general public suffix checklist. For instance, by including exampleusercontent.com to the PSL, you’ll be able to be certain that foo.exampleusercontent.com and bar.exampleusercontent.com are cross-site and thus totally remoted from one another.
URLs matching *.exampleusercontent.com/shim are all routed to a static shim file. This shim file accommodates a brief HTML/JS snippet that listens to the message occasion handler and renders any content material it receives.
To make use of this, the product creates both an iframe or a popup to $RANDOM_VALUE.exampleusercontent.com/shim and makes use of postMessage to ship the untrusted content material to the shim for rendering.
The rendered content material is reworked to a Blob and rendered inside a sandboxed iframe.
In comparison with the traditional sandbox area method, this ensures that every one content material is totally remoted on a novel web site. And, by having the primary software take care of retrieving the information to be rendered, it’s not obligatory to make use of functionality URLs.
Collectively, these two options make it doable emigrate off of traditional sandbox domains like googleusercontent.com to safer options which might be appropriate with third-party cookie blocking. At Google, we’ve already migrated many merchandise to make use of these options and have extra migrations deliberate for the subsequent yr. We hope that by sharing these options, we might help different web sites simply serve untrusted content material in a safe method.
[ad_2]