Difference between revisions of "Cross-Origin iFrame"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Context)
Line 6: Line 6:
 
* [[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]].
 
* [[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.
 
* 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. Also this is the way that data protection laws have been written.
+
* 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.
  
 
==Problems==
 
==Problems==

Revision as of 10:04, 12 March 2021

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.

Problems

  • 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 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.

Solutions

  • The browser (or user agent) is not 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.

References