Cross-Origin iFrame

From MgmtWiki
Revision as of 16:39, 12 March 2021 by Tom (talk | contribs) (Cross Site Scripting)

Jump to: navigation, search

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 (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 (HTML Document Object Model) 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".

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.

References