Recently I discussed the general problems of objects and it's context in which they maybe behave like IFRAMES. Strictly speaking HTML's multimedia features allow the OBJECT HTML to include images, iframes, applets, and other rich content like Flash and movie clips. Previously HTML did allow content to be fetched from an applet as well. To embed another document, whether local or remote, we can utilize the IFRAME, the FRAMESET, EMBED or the OBJECT.

Generic embedding of content.

The w3c specification below shows all possible attributes that are allowed for an OBJECT[1]

<!ELEMENT OBJECT - - (PARAM | %flow;)*
 -- generic embedded object -->

<!ATTLIST OBJECT
 %attrs; -- %coreattrs, %i18n, %events --
 declare (declare) #IMPLIED -- declare but don't instantiate flag --
 classid %URI; #IMPLIED -- identifies an implementation --
 codebase %URI; #IMPLIED -- base URI for classid, data, archive--
 data %URI; #IMPLIED -- reference to object's data --
 type %ContentType; #IMPLIED -- content type for data --
 codetype %ContentType; #IMPLIED -- content type for code --
 archive CDATA #IMPLIED -- space-separated list of URIs --
 standby %Text; #IMPLIED -- message to show while loading --
 height %Length; #IMPLIED -- override height --
 width %Length; #IMPLIED -- override width --
 usemap %URI; #IMPLIED -- use client-side image map --
 name CDATA #IMPLIED -- submit as part of form --
 tabindex NUMBER #IMPLIED -- position in tabbing order --
 >

Embed content via an OBJECT.

Normally, CODEBASE and CLASSID are used to fetch data for an OBJECT, similarly for APPLETS. However, the DATA attribute makes it possible to render an OBJECT as an embedded IFRAME as we can see in the example below. In figure 1 we see a regular IFRAME that is successfully blocked by NoScript. Figure 2 shows an OBJECT that is rendered as an IFRAME, successfully bypassing the IFRAME protection.

The code below allows for remote embedding as seen in figure 2.

<object data="http://www.google.com" width="200" height="200"></object>

This will successfully fetch the document residing on a remote server, and start to act as an IFRAME. The latest version of NoScript allows it's users to block iframes in order to protect themselves from “Clickjacking”. Whether or not Clickjacking works with Iframes, I do not know since the details are not released by Hansen, Grossman et al[2]. Certainly NoScript's current protection will fail if an OBJECT is used to replace an IFRAME, making it vulnerable for bypassing it's protection a priori.

Moreover, it is important to know that one does not need Javascript to hijack “clicks” or other mouse-events. I discussed hijacking events on a LABEL element to pass the event through to a submit button, exactly one month ago[3] This way, one is able to hijack user events to perform a CSRF for example, or hijack forms/iframes with it[4], and is nearly impossible to prevent because it does not rely on Javascript at all.

Fix.

Giorgio released a fix for NoScript. You can download the latest version of NoScript with additional protection right here: 1.8.1.9, upgrade

[1] http://www.w3.org/TR/REC-html40/struct/objects.html
[2] http://ha.ckers.org/blog/20080915/clickjacking/
[3] http://www.0x000000.com/index.php?i=312
[4] http://trickeries.com/216/an-interesting-csrf-attack/
source: OWASP News