Movatterモバイル変換

1.Introduction

This section is not normative.

Modern Web applications are conglomerations of JavaScript written by multiple authors. Authors routinely incorporate third-party scripts into their applications and share user data with third-party services (e.g., as part of amashup). Unfortunately, in the existing model, the user’s data confidentiality and integrity is put at risk when one incorporates untrusted third-party code or shares data with untrusted third-party services.

Mechanisms such as CORS and CSP can be used to mitigate these risks by giving authors control over whom they share data with. But, once data is shared, these mechanisms do not impose any restrictions on how the code that was granted access can further disseminate the data.

This document specifies an extension to the current model called Confinement with Origin Web Labels (COWL). COWL provides authors with APIs for specifying (mandatory) access control policies on data, including content, in terms oforigin labels. These policies are enforced in a mandatory fashion, transitively, even once code has access to the data. For example, with COWL, the author ofhttps://example.com can specify that a password is confidential tohttps://example.com (and thus should only be disclosed tohttps://example.com) before sharing it with a third-party password strength checking service. In turn, COWL ensures that the third-party service, which necessarily computes on the sensitive password, is confined and respects the policy on the password: COWL disallows it from disclosing the password to anyorigin other thanhttps://example.com.

COWL enforces such policies by confining code at thecontext-level, according to the sensitivity (i.e., the label) of the data the code has observed. To reap the greatest benefits of COWL, authors will need to compartmentalize applications into multiple contexts (e.g.,iframes).

In the existing model, any page served from an origin has the ambient, implicit authority of that origin. This documents generalizes this notion of authority and gives authors explicit control over it withprivileges. For example, by default, a page whose origin ishttps://example.com has the privilege forhttps://example.com. This gives the page the authority to arbitrarily disseminate data sensitive tohttps://example.com; to be backwards-compatible, the page is not confined when reading data sensitive tohttps://example.com. However, COWL allows the author to run the page with "weaker"delegated privileges (e.g., one corresponding the current user athttps://example.com) or to drop the privilege altogether.

COWL is intended to be used as a defense-in-depth mechanism that can restrict how untrusted—buggy but not malicious—code handles sensitive data. Given the complexities of browser implementations and presence of covert channels, malicious code may be able to exfiltrate data. Authors should still use discretionary access control mechanisms, such as CSP and CORS, to restrict access to the data in the first place.

1.1.Goals

The goal of COWL is to provide authors with a means for protecting the confidentiality and integrity of data that is shared with untrusted code, whether third-party or their own. Existing mechanisms (e.g., CORS’sAccess-Control-Allow-Origin header and thetargetOrigin argument topostMessage()) provide a way for restricting whichorigins may access the shared data. But, once content has access to data it can usually disseminate it without restrictions. While CSP can be used to confine code, i.e., restrict how confidential data is disseminated, setting a correct CSP policy (as to confine code) is difficult and limited to content the author has control over. Indeed, sharing confidential data in the existing model almost always requires the sender to trust the receiver not to leak the data, accidentally or otherwise. COWL provides a defense-in-depth option for protecting data confidentiality and integrity. In particular, with COWL:

Authors should be able to specify confidentiality and integrity policies on data in terms of origin labels: the origins to whom the data is confidential and the origins that endorse the data. This allows authors to share sensitive data with third-party content and impose restrictions on the origins with which it can communicate once it inspects the sensitive data. Dually, it allows authors to share data via intermediate content while retaining its integrity.
Authors should be able to run code withleast privilege by restricting the origins the code can communicate with and thus how it can disseminate sensitive data.
Authors should be able toprivilege separate applications by compartmentalizing them into separate contexts that havedelegated privileges.

1.2.Use Cases/Examples

1.2.1.Confining untrusted third-party services

An author wishes to use a service, loaded in the form of an iframe, without trusting it (or its dependencies) to not leak her sensitive data. To protect the data, the author associates a confidentialitylabel with the data, specifying the origins allowed to read the data. The author then shares the newly createdlabeled object with the untrusted code. In turn, COWL confines the untrusted code once it inspects the sensitive data, as to ensure that it can only communicate according to the author-specified policy (the label).

The author ofhttps://example.com wishes to use a third-party password strength checker provided byhttps://untrusted.com. To protect the confidentiality of the password, thehttps://example.com application can use COWL to associate a confidentiality policy, in the form of alabel, with the password before sending it to the untrusted service:

// Create new policy usingLabels that specifies that the password is sensitive// to https://example.com and should only be disclosed to this origin:var policy = newLabel(window.location.origin);// Associate the label with the password:var labeledPassword = newLabeledObject(password, {confidentiality: policy});// Send the labeled password to the checker iframe:checker.postMessage(labeledPassword, "https://untrusted.com");// Register listener to receive a response from checker, etc.

Once the checker inspects theprotected object, i.e., the password, COWL limits the iframe to communicating with origins that preserve the password’s confidentiality (in this case,https://example.com). This policy is enforced mandatorily, even if thehttps://untrusted.com iframe sends the password to yet another iframe.

Note, until the checker actually inspects the labeled password, it can freely communicate with any origins, e.g., withhttps://untrusted.com. This is important since the checker may need to fetch resources (e.g., regular expressions) to check the password strength. This is also safe—the checker has not inspected the sensitive password, and thus need not be confined.

Other use cases in this category include password managers and encrypted document editors, for example, where an encryption/decryption layer and a storage layer are provided by distrusting, but not malicious, services. The academic paper on COWL describes these use cases in detail[COWL-OSDI].

1.2.2.Sharing data with third-party mashups

A server operator wishes to provide third-party mashups access to user data. In addition to using CORS response headers to restrict theorigins that can access the data[CORS], the operator wishes to restrict how the data is further disseminated by these origins. To do so, the operator sends a response header field namedSec-COWL (described in§3.5.2 The Sec-COWL HTTP Response Header Field) whose value contains the sensitivity of the data in the form of a serialized confidentialitylabel. In turn, COWL enforces the label restrictions on the third-party code.

The server operator ofhttps://provider.com uses a CORS response header to granthttps://mashup.com access to a resource. The operator also sets a COWL header to specify that the resource is confidential tohttps://provider.com and should not be disseminated arbitrarily:

Access-Control-Allow-Origin: https://mashup.comSec-COWL:data-confidentiality [ ["https://provider.com"] ]

COWL only allows ahttps://mashup.com context to read the sensitive response if the label restrictions of the response are respected, i.e., if the code can only communicate withhttps://provider.com.

Note, COWL only allows the code to inspect the response if thecontext labels, which dictate the context’s ability to communicate, are more restricting than the labels of the response. A more permissive approach, which does not require the context give up its ability to communicate arbitrarily is to uselabeled JSON response. Themashup XHR example shows how authors can accomplish this.

1.2.3.Content isolation via privilege separation

A server operator wishes to isolate content (e.g., of different users) while serving it from a single physicalorigin. The operator can leverageprivileges to ensure that content of one part of the site has different authority from another and, importantly, does not have authority of the physical origin. Concretely, when serving content, the operator can set the content’scontext privilege to a weaker,delegated privilege. This ensures that the content are privilege separated.

Supposehttps://university.edu wished to isolate different parts of their site according to users. The server operator can weaken the privilege of a page when serving user content by providing a response header field namedSec-COWL (see§3.5.2 The Sec-COWL HTTP Response Header Field) whose value contains a serializeddelegated privilege. For example, for any content underhttps://university.edu/~user1, the following header is set:

Sec-COWL:ctx-privilege [ ['self', 'cowl://user1'] ]

Having this privilege can be understood as having the authority ofuser1’s part of thehttps://university.edu origin. COWL ensures that the content of this user cannot interfere with the content ofhttps://university.edu or another user e.g.,user2. For example, the content cannot modifyhttps://university.edu cookies or the DOM of anotherhttp://university.edu page.

Thisdelegated privilege also ensures that the content cannot disseminate data sensitive to another user (e.g.,user2) arbitrarily— without being confined, it can only disseminateuser1’s data onhttp://university.edu. Of course, this requires the server operator to label sensitive data (e.g., when sending it to the user agent) appropriately (e.g.,user2’s data is labeledLabel("https://university.edu")._or("user2")).

Thesub-origin isolation in JavaScript example shows how this can be implemented using the COWL JavaScript APIs.

Note, sub-domains should be used when possible to ensure that content is isolated using the Same-Origin Policy. But, even in such cases, COWL can provide a useful layer of defense.

1.2.4.Running content with least-privileges

An author wishes to use a library that is tightly coupled with the page (e.g., jQuery), but not trust it to protect the user’s confidentiality and integrity. With COWL, the author can do this by loading the untrusted library afterdropping privileges (from the context’sdefault privilege). In doing so, the content (and thus the library) loses its implicit authority over the content’s origin.

The author ofhttps://example.com can drop privileges in #"dfn" href="#context-privilege">context privilege to anempty privilege:COWL.privilege = newPrivilege();// Load untrusted library

Or, by setting the content’s initial privilege to theempty privilege usingSec-COWL response header:

Sec-COWL:ctx-privilege [ [] ]

Note, while this ensures that the context code cannot, for instance, access the origin’s cookies, the author must still associate a confidentiality label with resources (e.g., HTTP responses) to ensure that data is properly protected.

In some cases it is useful for a particular context to have the privilege to disseminate certain categories of data. (Theor part oflabels can be used to easily categorize differently-sensitive data.) To this end, the author should run the context with adelegated privilege instead of theempty privilege. The above§1.2.3 Content isolation via privilege separation shows one such example.

1.3.Trust Model

COWL provides developers with a way of imposing restrictions on how untrusted code can disseminate sensitive data. However, authors should avoid sharing sensitive data with malicious code, since such code may be able to exploit covert channels, which are present in most browsers, to leak the data. COWL can only prevent information leakage from code that (e.g., is buggy and) uses overt communication channels.

Similarly, COWL provides no guarantees against attacks wherein users are manipulated into leaking sensitive data via out-of-band channels. For example, an attacker may be able to convince a user to navigate their user agent to an attacker-owned origin by entering a URL that contains sensitive information into the user agent’s address bar.

COWL should always be used as an additional layer of defense to other security mechanisms such as CSP, SRI, CORS, and iframesandbox.

2.Key Concepts and Terminology

2.1.Labels

Anorigin label, or more succinctly alabel, encodes either a confidentiality or integrity security policy as conjunctive normal form (AND’s and OR’s) formulae overorigins. Labels can be associated withcontexts or withstructurally clonable objects.
When associated with acontext, the label restricts the origins that the context can communicate with, as detailed in§3.3 Labeled Contexts.
The confidentiality labelLabel("https://a.com")._or("https://b.com"), when associated with a context, restricts the context to sending data tohttps://a.com orhttps://b.com, but no other origins. This context label reflects the fact the context may contain data that is sensitive to eitherhttps://a.com orhttps://b.com; it is thus only safe for it to communicateto these origins.
Note, because the context can communicate data to either origin, another context associated with the more restricting labelLabel("https://a.com") cannot send it data. Doing so would allow for data confidential tohttps://a.com to be leaked tohttps://b.com.
The integrity labelLabel("https://a.com").or("https://b.com"), when associated with a context, restricts the context to receiving data from (a context or server) that is at least as trustworthy ashttps://a.com orhttps://b.com. This context label ensures that the code running in the context can only be influenced by data which eitherhttps://a.com orhttps://b.com endorse.
When associated with an object, a confidentiality label specifies the origins to whom the object is sensitive, while an integrity label specifies the origins that endorse the object. Objects that have labels associated with them are calledlabeled objects.§3.4 Labeled Objects defines how labels are associated with objects.
Consider anhttps://example.com page that receives a labeled object (e.g., viapostMessage()) with the following labels:
- Confidentiality:Label("https://example.com").This label indicates that the object is sensitive tohttps://example.com.
- Integrity:Label("https://a.com"). Thislabel indicates that the object has been endorsed byhttps://a.com. Ifhttps://example.com received the message from anintermediaryhttps://b.com context, this labelreflects the fact that the object (produced byhttps://a.com) was not tampered.
Mathematically, a label is aconjunctive normal form formula over origins[DCLabels].
A label is innormal form if reducing it according to thelabel normal form reduction algorithm produces the same value.
Two labels areequivalent if theirnormal form values are mathematically equal.
A labelAsubsumes (or is morerestricting than) another labelB if the result of running thelabel subsumption algorithm on thenormal forms ofA andB returnstrue. Labels are partially ordered according to this subsumes relation.
Thecurrent confidentiality label is the confidentiality label associated with the current context.§3.3 Labeled Contexts specifies how labels are associated with contexts.
Thecurrent integrity label is the integrity label associated with the current context.§3.3 Labeled Contexts specifies how labels are associated with contexts.
When reading alabeled object, a context getstainted, i.e., itscontext labels are updated by invokingcontext tainting algorithm, to reflect that it has read sensitive (of potentially different trustworthiness) data and should be confined accordingly.

2.2.Privileges

Aprivilege is an unforgeable object that corresponds to alabel. Privileges are associated with contexts and reflect their authority.
Privileges can be used to bypass confinement restrictions imposed by confidentiality labels. In particular, a privilege can be used to bypass the restrictions imposed by any label its corresponding label—theinternal privilege label—subsumes.
Consider a context fromhttps://a.com whosecurrent confidentiality label isLabel("https://a.com").and("https://b.com"). This label confines the context to only communicating with entities whose labels are at least as restricting as this label. For example, it restricts the context from communicating with a context labeledLabel("https://b.com"), since doing so could leakhttps://a.com data tohttps://b.com. It similarly prevents the context from communicating withhttps://a.com.
But, suppose that the context’scurrent privilege corresponds toLabel("https://a.com") (afterall, the context originated fromhttps://a.com). Then, the context would be able to bypass some of the restrictions imposed by the context label. Specifically, the context would be able to communicate withhttps://b.com; the privilege confers it the right to declassifyhttps://a.com data tohttps://b.com. Indeed, when taking this privilege into consideration, theeffective confidentiality label of the context isLabel("https://b.com").
Note, the privilege does not allow the context to bypass any label restrictions. For example, it does not allow the context to communicate withhttps://a.com since doing so could leakhttps://b.com data.
To be flexible, COWL uses the context privilege to remove certain restrictions imposed by thecontext label. To avoid accidentally leaking sensitive context data, authors should useLabeledObjects.
Privileges can also be used to bypass integrity restrictions imposed by integrity labels. In particular, a privilege can be used to endorse an otherwise untrustworthy labeledcontext (orlabeled object) as to allow it to communicate with more trustworthy end-points (another context or server).
Consider anhttps://a.com context whosecurrent integrity label isLabel("https://a.com")._or("https://b.com"). This label confines the context to only communicating with entities that are at most as trustworthy as this label. For example, it restricts the context from communicating with a context whosecurrent integrity label isLabel("https://a.com"), since doing so would potentially corrupthttps://a.com data (e.g., by allowinghttps://b.com to influence the computation).
But, if the context’scurrent privilege corresponds toLabel("https://a.com"), the context would be able to bypass some of these integrity restrictions. Specifically, the context would be able to communicate with the more-trustworthy context (labeledLabel("https://a.com")) since the privilege confers it the right to endorse (or vouch for) its context on behalf ofhttps://a.com. Indeed, when taking privileges into account, theeffective integrity label of the context isLabel("https://a.com").
Note, the privilege cannot be used to bypass any integrity restrictions. For example, it does not allow the context to communicate with a context whose integrity label isLabel(https://b.com).
Note,browsing contexts have acurrent privilege that, by default, corresponds to the origin of the context, as described in§3.3 Labeled Contexts. But, authors should set thecurrent privilege to adelegated privilege to follow the principle of least privilege.
Thecurrent privilege is the privilege associated with the current context.§3.3 Labeled Contexts specifies how privileges are associated with contexts.
Theeffective confidentiality label is the label returned by thelabel downgrade algorithm when invoked with thecurrent confidentiality label andcurrent privilege.
Theeffective integrity label is the label returned by thelabel upgrade algorithm when invoked with thecurrent integrity label andcurrent privilege.
Code can takeownership of aprivilegepriv by setting thecurrent privilege to the privilege produced via thecombination of thecurrent privilege andpriv. In doing so, it is said that the contextowns the privilege.

3.Framework

This sub-section is not normative.

In a nut-shell, the COWL framework provides:

Policy specification viaorigin labels: COWL provides aLabel interface for specifying confidentiality and integrity policies in terms oforigins.Labels can be associated with data and content using the JavaScriptLabeledObject andCOWL interfaces or theSec-COWL HTTP headers.
Explicit authority viaprivileges: The COWL framework provides a JavaScriptPrivilege interface for operating on and minting newprivileges. TheCOWL JavaScript interface andSec-COWL HTTP response header can be used to explicitly control the authority of a context by setting thecontext privilege.
Confinement enforcement mechanism: COWL extendsbrowsing contexts andWorkers with labels and privileges, which are used when enforcing confinement, i.e., when restricting a context’s network and cross-context messaging communication. This document defines the necessary changes and extensions to existing browser constructs and algorithms to enforce confinement.

3.1.Labels

Eachlabel is an immutable object represented by aLabel object, the interface of which is defined in this section.

ALabel MUST have an internallabel set, which is a non-empty set ofdisjunction sets.

Adisjunction set is a set oforigin URLs.

A label is said to be anempty label if itslabel set contains a single, emptydisjunction set.

[Constructor,Constructor(DOMStringorigin), Exposed=Window, Worker]interfaceLabel {  booleanequals(Labelother);  booleansubsumes(Labelother, optionalPrivilegepriv);Labeland((Label or DOMString)other);Label_or((Label or DOMString)other);  objecttoJSON();  [Throws] staticLabelfromJSON(objectobj, optional DOMStringself);};

Current WebIDL implementation requires an underscore for certain identifiers. Can we rename_or toor?

3.1.1.Constructors

Label()

When invoking theLabel() constructor, the user agent MUST return a newempty label.

Label(DOMString origin)

When invoking theLabel(origin) constructor, the user agent MUST use an algorithm equivalent to the following:

If theorigin argument is not aURL, the constructor MUST throw aTypeError exception[ECMA-262] and terminate this algorithm.
Else, it MUST return a newLabel that contains alabel set of a singledisjunction set, which itself MUST contain theURL corresponding to theorigin of the parameter.

3.1.2.Methods

equals(Label other)

The user agent MUST returntrue if theLabel on which the method has been called isequivalent to theother parameter; otherwise it MUST returnfalse.

subsumes(Label other, optional Privilege priv)