Securely Hosting User Data in Modern Web Applications

0
496
Securely Hosting User Data in Modern Web Applications


Many net purposes have to show user-controlled content material. This might be so simple as serving user-uploaded pictures (e.g. profile photographs), or as complicated as rendering user-controlled HTML (e.g. an online growth tutorial). This has all the time been tough to do securely, so we’ve labored to seek out straightforward, however safe options that may be utilized to most kinds of net purposes.

The traditional answer for securely serving user-controlled content material is to make use of what are generally known as “sandbox domains”. The fundamental concept is that in case your utility’s important 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 impression instance.com.

This method can be utilized to soundly serve every kind of untrusted content material together with pictures, downloads, and HTML. While it might not appear to be 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 extensively used throughout the trade and have labored properly for a very long time. But, they’ve two main downsides:

  1. Applications usually want to limit content material entry to a single person, which requires implementing authentication and authorization. Since sandbox domains purposefully don’t share cookies with the primary utility area, that is very tough to do securely. To help authentication, websites both should depend on capability URLs, or they should set separate authentication cookies for the sandbox area. This second methodology is particularly problematic within the fashionable net the place many browsers prohibit cross-site cookies by default.
  2. While person content material is remoted from the primary website, it isn’t remoted from different person content material. This creates the chance of malicious person content material attacking different information on the sandbox area (e.g. by way of studying same-origin information).

It can also be price 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 many alternative approaches right here, so we are going to define two options which can be presently in extensive use at Google.

Approach 1: Serving Inactive User Content

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

  1. Always set the Content-Type header to a well known MIME kind that’s supported by all browsers and assured to not include energetic content material (when unsure, utility/octet-stream is a secure alternative).
  2. In addition, all the time set the beneath response headers to make sure that the browser absolutely isolates the response.

Response Header

Purpose

X-Content-Type-Options: nosniff

Prevents content material sniffing

Content-Disposition: attachment; filename="obtain"

Triggers a obtain quite than rendering

Content-Security-Policy: sandbox

Sandboxes the content material as if it was served on a separate area

Content-Security-Policy: default-src ‘none’

Disables JS execution (and inclusion of any subresources)

Cross-Origin-Resource-Policy: 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 utility, or downloaded as a file by the person. Furthermore, the headers present a number of layers of safety in opposition to browser bugs via the CSP sandbox header and the default-src restriction. Overall, the setup outlined above gives a excessive diploma of confidence that responses served on this means can’t result in injection or isolation vulnerabilities.

Defense In Depth

While the above answer represents a usually ample protection in opposition to XSS, there are a selection of further hardening measures which you could apply to offer further layers of safety:

  • Set a X-Content-Security-Policy: sandbox header for compatibility with IE11
  • Set a Content-Security-Policy: frame-ancestors 'none' header to dam the endpoint from being embedded
  • Sandbox person content material on an remoted subdomain by:
    • Serving person content material on an remoted subdomain (e.g. Google makes use of domains equivalent to product.usercontent.google.com)
    • Set Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp to allow cross-origin isolation

Approach 2: Serving Active User Content

Safely serving energetic content material (e.g. HTML or SVG pictures) may also be carried out with out the weaknesses of the traditional sandbox area method.

The easiest possibility is to make the most of the Content-Security-Policy: sandbox header to inform the browser to isolate the response. While not all net browsers presently implement course of isolation for sandbox paperwork, ongoing refinements to browser course of fashions are possible to enhance the separation of sandboxed content material from embedding purposes. If SpectreJS and renderer compromise assaults are exterior of your risk mannequin, then utilizing CSP sandbox is probably going a ample answer.

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

  1. Create a brand new sandbox area that’s added to the public suffix record. For instance, by including exampleusercontent.com to the PSL, you may 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 comprises a brief HTML/JS snippet that listens to the message occasion handler and renders any content material it receives.
  3. To use 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.

Compared to the traditional sandbox area method, this ensures that each one content material is absolutely remoted on a novel website. And, by having the primary utility take care of retrieving the information to be rendered, it’s not obligatory to make use of functionality URLs.

Together, these two options make it attainable emigrate off of traditional sandbox domains like googleusercontent.com to safer options which can 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 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

Please enter your comment!
Please enter your name here