Commit 0aa7d608 authored by Dietrich Ayala's avatar Dietrich Ayala
Browse files

Draft requirements for same-origin-policy

parent 3e350c5e
Loading
Loading
Loading
Loading
+30 −0
Original line number Diff line number Diff line
@@ -145,6 +145,9 @@ For the purposes of the present document, the terms given in Regulation (EU) 202

<mark>Editor's Note: Proposal to put together a common term sheet for all verticals developed in CYBER-EUSR.</mark>

Origin: An origin in browser products is the compound of the scheme, host and port of a web resource. When a web resource defined as valid in the user documentation cannot be formed into a meaningful combination of host, scheme and port, the product constructs a synthetic origin uniquely identifying the resource.

Same-origin policy: A security model in browser products used to determine whether assets and state should be shared or not between web page execution contexts.

## 3.2 Symbols

@@ -200,6 +203,7 @@ For the purposes of the present document, the [following] abbreviations [given i
`SIEM  Security Information and Event Management`  
`SIF   Social Interactive Function`  
`SOAR  Security Orchestration Automation and Response`  
`SOP   Same-origin policy`
`TLS   Transport Layer Security`  
`TUF   The Update Framework`  
`UC    Use Case`  
@@ -437,6 +441,18 @@ Example: Permissions divided such that an extension can request and access the m

**[REQ-EXT-AAC-6]**: The product shall ensure isolation between the execution and data contexts of different extensions.

**[REQ-SOP-AAC-1]**: The product shall deny access in one origin to all parts of another origin, except as defined in the user documentation.

Example: Web pages may load images from other origins, message using `window.postMessage` and may access limited properties such as `Location`. Web pages may not access the document object model or global Window scope from scripts of other origins. The user documentation references industry standards with implementation recommendations and additinal examples.

**[REQ-SOP-AAC-2]**: The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any other storage, ensuring it's not available to any other origin, except through protocol-determined methods.

<mark>Editor's note: is this limited to top-level pages?</mark>

<mark>Editor's note: are cookies awkward here? in what way?</mark>

<mark>Editor's note: need to add examples for cross domain storage access is allowed, etc.</mark>

## 5.6 Confidentiality

Proposed ESR code: CON
@@ -463,6 +479,16 @@ Example: Implementation of HSTS [i.8], active mixed content blocking [i.9], and

**[REQ-EXT-CON-1]**: The product shall prevent secrets stored by extensions from being read by other extensions or by web content.

**[REQ-SOP-CON-1]**: The product shall only allow scripts to access the body of a cross-origin HTTP response where the source origin has opted to allow access by the requesting origin.

Example: Implementation of Cross-Origin Resource Sharing (CORS)

**[REQ-SOP-CON-2]**: Where the product allows cross-origin embedding of a resource in documents, the product shall limit information about that resource as specified in the technical documentation.

Example: Cross-origin embedding of the height and width of an image are exposed to scripts, while the contents of the image are not exposed unless CORS is enabled by the source origin of the image.

<mark>Editor's note: In principle, CON-1 might imply CON-2, and maybe we could put this all in assessment steps. Or maybe better to be explicit?</mark>

## 5.7 Integrity

Proposed ESR code: INT
@@ -530,6 +556,10 @@ Example: Extensions may bundle assets in their packages, and browsers may allow

**[REQ-ISO-MAS-1]**: The product's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

**[REQ-SOP-MAS-1]**: The product shall enforce restrictions from a source origin on how its resources may be used across origins, as defined in the user documentation.

Example: Usage of cross-origin options such as `X-Frame-Options` or `Cross-Origin-Resource-Policy` allow source origins to specify usage constraints for products to receive and enforce.

## 5.12 Exploitation Mitigation Mechanisms

Proposed ESR code: EMM