Difference between revisions of "Cross-Origin iFrame"

Latest revision as of 09:51, 14 August 2024

Full Title or Meme

The Inline Frame, or iFrame was introduced to allow isolated web pages from unrelated entities to embed content seamlessly into a web page.

Context

• Frames and Framesets were introduced early in browser history to enable refreshing only a portion of a web page to improve responsiveness of web pages in the days of low bandwidth data communications.
• Identity features like OpenID Connect and WebAuthn 2 depends on the Cross-Origin iFrame for a seamless User Experience when identity is provided by a different web site than the Relying Party.
• Early on security was addressed If they’re not from the same domain, the parent HTML document and the iframe don’t have access to each other’s CSS styles, DOM or JavaScript functions, cookies, or local storage.
• This page is oriented towards the security of the user, unlike most web sites which are typically concerned only with data under their control, as this is the way that data protection laws have been written.

Taxonomy

• DOM = Document Object Model resident in a "window" object in an HTML based user agent (typically a browser).
• COEP: Cross Origin Embedder Policy
• COOP: Cross Origin Opener Policy - a softening of this policy was proposed (2022-07-26)
• CORP: Cross Origin Resource Policy
• CORS: Cross Origin Resource Sharing
• CORB: Cross Origin Read Blocking which (2022) is being replaces by ORB = Opaque Response Blocking.For more information please see https://www.chromium.org/Home/chromium-security/corb-for-developers.
• Sandbox is an iFrame attribute that contains the properties listed below.
• Same Domain policy, as used above, has been replaced by policy on the same origin and site. A domain is the part after the scheme e,g, www.example.com.
• Origin is a combination of a scheme (also known as the protocol, for example HTTP or HTTPS), hostname, and port (if specified). For example, given a URL of https://www.example.com:443/foo , the "origin" is https://www.example.com:443.
• Site is the TLD and the part of the domain just before it. eg. for https://www.example.com:443/foo , the "site" is example.com.
  • TLD = Top Level Domain, like .com, .us or .solutions.
  • Effective TLD can be .co.jp or .com. for tips;//my-project.github.io:443 the site is my-project.github.io as getup.io is considered to be the effective tld.
  • Public Suffix List defines the ETLDs.
• First Party = the Origin
• Second Party = the user on their browser
• Third Party = anyone else, typically an advertisement or an Identity Provider
• Trusted Third Party (TTP) is a web site with a certificate that makes some claim about the trustworthiness of the site.

Problems

• The user has no real control over the JavaScript that is embedded in the HTML pages that are loaded by a web site onto the browser running on their computer.
• Advertisers have exploited the iFrame and cookies to track users across multiple origin sites.
• The user is somewhat at the mercy of the web site in that the site is more interested in gaining users than in their security.
• Limitations that have been placed on iFrames can (with the exception of running plugins) be disabled by the source web site which does not fully share the user's security concerns.

1. Run plug-ins
2. Submit forms - disabled by allow-forms
3. Change the parent web page’s URL - disabled by allow-top-navigation
4. Read cookies or local storage, even if it’s from the parent domain
5. Open new tabs, new windows or Pop-up Windows - partially disabled by allow-popups
6. Run any JavaScript (even if it would only impact what’s inside the iFrame) - disabled by allow-scripts.
7. Access data from Origin URL - allow-same-origin

Cross Site Scripting

Cross Web Site Scripting (XSS) Attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

Client-side script, or DOM based XSS attacks are downloaded (or locally modified) into the DOM so that JavaScript from the web site can be made to perform malicious activity on behalf of an attacker that is not known to the Relying Party web site. This and similar client-side attacks have been documented and weaponized for running by "script kiddies".

Scheme-full SameSite

The SameSite cookie attribute offers defense against CSRF attacks but currently does not consider secure and insecure version of the same domain as being cross-site; because of this, a network attacker could impersonate http://site.example (or a subdomain) and use that to bypass SameSite protections on https://site.example. Changing the SameSite computation to consider http://site.example and https://site.example as cross-site negates this type of attack.

• Note that WebSockets requests can send cookies but use different schemes from http(s). For purposes of this comparison wss:// and https:// are considered the same and similarly for ws:// and http://.
• Explainer
• To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/72a2df2a-a5f2-4d0b-8234-029e0ee884cb%40chromium.org.

Other Annoyances

iFrames bring other annoyances, like messing up the behavior of the back button or accessibility functionality. With two different teams working on the main frame and iframe, weird interactions are inevitable.

Solutions

• The browser (or user agent) is now being sold to user's as an instrument of user protection. This attitude by the browser manufactures picked up relevance when Apple began advertising their privacy features to consumers in 2020 and earlier.

Window

• The "window" interface is a pointer to an object that contains a DOM which is a collection of all the functions, namespaces, objects as well as the more commonly understood User Interface.elements.
• When we access something inside embedded window, the browser checks if the iframe has the same origin. If that’s not so then the access is denied (writing to location is an exception, it’s still permitted).
• In a tabbed browser, each tab starts out as a single window object, but can spawn additional windows with each iFrame.
• Some of the window properties of interest to this wiki (that are not deprecated) are:

1. Window.isSecureContext - Read only Experimental - Indicates whether a context is capable of using features that require secure contexts.
2. WindowOrWorkerGlobalScope.caches - Read only - Returns the CacheStorage object associated with the current context. This object enables functionality such as storing assets for offline use, and generating custom responses to requests.
3. WindowOrWorkerGlobalScope.indexedDB - Read only - Provides a mechanism for applications to asynchronously access capabilities of indexed databases; returns an IDBFactory object.
4. WindowOrWorkerGlobalScope.isSecureContext - Read only - Returns a boolean indicating whether the current context is secure (true) or not (false).
5. WindowOrWorkerGlobalScope.crossOriginIsolated - Read only Experimental not in non-Chrome phones or in Apple - The crossOriginIsolated read-only property of the WindowOrWorkerGlobalScope interface returns a boolean value that indicates whether a SharedArrayBuffer can be sent via a Window.postMessage() call. This value is dependent on any policy headers (see below) present in the response. (valid on 2021-03-15) These are the privileged features supported:
   1. SharedArrayBuffer Required for WebAssembly Threads. This is available from Android Chrome 88. Desktop version is currently enabled by default with the help of Site Isolation, but will require the cross-origin isolated state and will be disabled by default in Chrome 91.
   2. performance.measureUserAgentSpecificMemory() Available from Chrome 89.
   3. performance.now(), performance.timeOrigin Currently available in many browsers with the resolution limited to 100 microseconds or higher. With cross-origin isolation, the resolution can be 5 microseconds or higher.
   4. blocks modification of document.domain. - which allows communications between SameSite documents
   5. JS Self-Profiling API Not available in any browsers on 2020-02-02
6. Window.postMessage() = Provides a secure means for one window to send a string of data to another window, which need not be within the same domain (origin?) as the first. The security comes from the fact that both the sender and receiver must make explicit calls to enable the transfer. (See limitations from crossOriginIsolated, COOP & COEP)

• The policy headers present in the response of interest to this wiki. These policy are opt-in by the Relying Party web site to enable an isolated environment called cross-origin isolated.

1. Cross-Origin-Opener-Policy (COOP) require-corp - set to same-origin to ensure that both are in the same browsing context and have access to each other via DOA APIs such as window.opener.
2. Cross-Origin-Embedder-Policy (COEP) same-origin - first ensure that CORP or CORS is enabled. Here is what you need to do depending on the nature of the resource:
   1. If the resource is expected to be loaded only from the same origin, set the Cross-Origin-Resource-Policy: same-origin header.
   2. If the resource is expected to be loaded only from the same site but cross origin, set the Cross-Origin-Resource-Policy: SameSite header.
   3. If the resource is loaded from cross origin(s) under your control, set the Cross-Origin-Resource-Policy: cross-origin header if possible.
   4. For cross origin resources that you have no control over:
      1. Use the crossorigin attribute in the loading HTML tag if the resource is served with CORS.
      2. Ask the owner of the resource to support either CORS or CORP.
   5. For iframes, use CORP and COEP headers as follows: Cross-Origin-Resource-Policy: same-origin (or SameSite, cross-origin depending on the context) and Cross-Origin-Embedder-Policy: require-corp.

Federated Learning of Cohorts

• Also known as The Privacy Sandbox was introduces in Chrome 89 stable on 2021-03-17

The FLoC API intends to provide callers (primarily ad-tech) with a "cohort label" shared by thousands of people with similar browsing habits to aid in interest-based online advertising. The browser will group people together into k-anonymous interest cohorts via purely on-device computation, and reveal the user’s cohort via script.

• This is Google's attempt to retain the advantages with targeted ads but without the same user privacy issues.
• What Google’s Privacy Sandbox Means for Internet Governance Elizabeth M. Renieris 2021-03-19 (error on date of release of Crome 89) Under the guise of heightened user privacy, Google’s replacement for third-party cookies will build more walls in the open web. The phase-out of third-party browser cookies is getting the most attention, specifically through Google’s proposed use of Federated Learning of Cohorts (FLoC), an unsupervised machine-learning algorithm for clustering people into groups for ad targeting based on their recent browsing history.
• Explainer on W3C WICG
• Explainer on Googe's support page
• Google Commits To Not Tracking Individual Users For Ad Targeting After Cookie Phase Out This paper is a regurgitation of Google's PR. 2021-03-03
• Google's FLoC Is a Terrible Idea per the Electronic Frontier Foundation Bennet Cyphers 2021-03-03
• Google and the Age of Privacy Theater Wired 2021-03-18 The demise of Surveillance capitalism has been greatly exaggerated.

Elimination of Third-Party Cookies

Google is announcing the FLoC with this message. (Note that Firefox and Safari take a bunt axe to third party cookies, rather than Google's attempt to preserve ad revenue)

• Google announced that they were Building a more private web: A path towards making third party cookies obsolete 2021-01-14. Quoting their website: "In August, we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. Our goal for this open source initiative is to make the web more private and secure for users, while also supporting publishers. ... Our intention is to do this within two years. But we cannot get there alone, and that’s why we need the ecosystem to engage on these proposals. We plan to start the first origin trials by the end of this year, starting with conversion measurement and following with personalization."
• The W3C effort is in the IMPROVING WEB ADVERTISING BUSINESS GROUP rather than in one of the technical committees.
• Google Effort to Kill Third-Party Cookies in Chrome Rolls Out in April with Chrome 90 release PC Magazine 2021-01-25. Other browsers, including Apple’s Safari and Mozilla’s Firefox, already block third-party cookies by default because the cookies can let companies profile your internet activities.
• This seems to be something like a head-fake as Google continues to push ads on the web with features like: Subresource loading with Web Bundles which has a goal of measuring its feature to improve Ad Serving. See WebBundles for Ad Serving for details.

First-party Sets

Introduces a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set. This proposal is for a simplified initial prototype.

Motivation

In support of potential browser privacy models to restrict cross-party tracking, web platform features can use First-Party Sets to determine whether embedded content may or may not access its own state. First-Party Sets define a more realistic “privacy boundary” by reflecting the real-world organization of websites, which often span multiple registrable domains.

Firefox's Enhanced Tracking Protection features use a list of "entities" maintained by Disconnect, so that third-party resources are not blocked if they belong to the same entity as the top-level site. Edge's tracking prevention feature includes an "Org Relationship Mitigation" that exempts third-party content from being blocked if the resource's URL belongs to the same organization as the requesting site. This proposal aims to standardize such behavior by introducing First-Party Sets as the web's privacy boundary, replacing the existing ad hoc and UA-specific behavior.

Some potential uses enabled by First-Party Sets are listed below. These are not in scope for the current proposal, and are listed here only for background. Separate proposals will be shared when these are ready to be prototyped:

• Cross-domain first-party cookies
• Partitioned network caches
• Anti-fingerprinting

Legacy security Headers

1. HTTP Strict Transport Security (HSTS) - everybody should do this. If a site is equipped with HTTPS, the server forces the browser to communicate over secure HTTPS. This way, the possibility of an HTTP connection is eliminated entirely. See wiki site TLS HSTS
2. Content Security Policy (CSP) - help protect against XSS, but not foolproof.
3. Cross Site Scripting Protection (X-XSS) - The browser filter doesn’t let the page load when it detects a cross-site scripting attack.
4. X-Frame-Options to block 'Clickjacking'
5. X-Content-Type-Options - The X-Content-Type header offers a countermeasure against MIME sniffing.

References

• The wiki page SameSite contains related material.
• The wiki page Browser Origin Policy contains related material.
• the wiki page Identifier use in Browsers contains the impact of controls on a Cross-Origin iFrame to the User Experience.
• The current Chrome Status can be used to see the current status any of these features. You will need to search on that very long page for the topic of interest.
• Potential Privacy Model for the Web Not clear on distinction among domain, origin and site, see above.
• 3 Reasons You Might Not Want To Use Iframes is somewhat older. It is written from perspective of devs not users. It sure shows that devs never think that they cause security problems.
• Iframes as a Security Feature does actually acknowledge some of the security problems with iFrames but mostly is oriented to Relying Party.