Securely Internet hosting Consumer Knowledge in Fashionable Internet Purposes


Many internet purposes must show user-controlled content material. This may be so simple as serving user-uploaded photographs (e.g. profile pictures), or as advanced as rendering user-controlled HTML (e.g. an online growth 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 kinds of internet purposes.

The basic answer for securely serving user-controlled content material is to make use of what are often called “sandbox domains”. The fundamental thought is that in case your software’s foremost area is instance.com, you possibly can serve all untrusted content material on exampleusercontent.com. Since these two domains are cross-site, any malicious content material on exampleusercontent.com can’t influence instance.com.

This method can be utilized to soundly serve all types of untrusted content material together with photographs, downloads, and HTML. Whereas it might not appear to be it’s crucial to make use of this for photographs or downloads, doing so helps keep away from dangers from content material sniffing, particularly in legacy browsers.

Sandbox domains are extensively used throughout the trade and have labored effectively for a very long time. However, they’ve two main downsides:

  1. Purposes 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 help authentication, websites both need to depend on functionality URLs, or they need to set separate authentication cookies for the sandbox area. This second methodology is particularly problematic within the fashionable internet the place many browsers limit cross-site cookies by default.
  2. Whereas consumer content material is remoted from the primary website, it isn’t remoted from different consumer content material. This creates the danger of malicious consumer content material attacking different information on the sandbox area (e.g. through studying same-origin information).

Additionally it is price noting that sandbox domains assist mitigate phishing dangers since sources 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 a lot of completely different approaches right here, so we’ll define two options which are presently in vast use at Google.

Method 1: Serving Inactive Consumer Content material

If a website solely must serve inactive consumer content material (i.e. content material that isn’t HTML/JS, for instance photographs and downloads), this will now be safely performed with out an remoted sandbox area. There are two key steps:

  1. At all times set the Content material-Sort header to a widely known MIME kind that’s supported by all browsers and assured to not include lively content material (when doubtful, software/octet-stream is a protected selection).
  2. As well as, at all times set the under response headers to make sure that the browser absolutely isolates the response.

Response Header

Function

X-Content material-Sort-Choices: nosniff

Prevents content material sniffing

Content material-Disposition: attachment; filename="obtain"

Triggers a obtain quite 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 mixture 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 by way of the CSP sandbox header and the default-src restriction. General, the setup outlined above offers a excessive diploma of confidence that responses served on this manner can’t result in injection or isolation vulnerabilities.

Protection In Depth

Whereas the above answer represents a typically ample protection towards XSS, there are a variety of extra hardening measures that you may apply to supply extra 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 Lively Consumer Content material

Safely serving lively content material (e.g. HTML or SVG photographs) may also be performed with out the weaknesses of the basic sandbox area method.

The only possibility is to reap the benefits of the Content material-Safety-Coverage: sandbox header to inform the browser to isolate the response. Whereas not all internet browsers presently implement course of isolation for sandbox paperwork, ongoing refinements to browser course of fashions are doubtless to enhance the separation of sandboxed content material from embedding purposes. If SpectreJS and renderer compromise assaults are outdoors of your menace mannequin, then utilizing CSP sandbox is probably going a ample answer.

At Google, we’ve developed an answer that may absolutely isolate untrusted lively content material by modernizing the idea of sandbox domains. The core thought is to:

  1. Create a brand new sandbox area that’s added to the public suffix listing. 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 absolutely remoted from one another.
  2. URLs matching *.exampleusercontent.com/shim are all routed to a static shim file. This shim file incorporates a brief HTML/JS snippet that listens to the message occasion handler and renders any content material it receives.
  3. 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.
  4. The rendered content material is remodeled to a Blob and rendered inside a sandboxed iframe.

In comparison with the basic sandbox area method, this ensures that every one content material is absolutely remoted on a novel website. And, by having the primary software take care of retrieving the info to be rendered, it’s not crucial to make use of functionality URLs.

Collectively, these two options make it potential emigrate off of basic sandbox domains like googleusercontent.com to safer options which are 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 following yr. We hope that by sharing these options, we may also help different web sites simply serve untrusted content material in a safe method.

Leave a Reply

Your email address will not be published. Required fields are marked *