What about this info?

[luntrus]

Hi users of NoScript,

We know that clickjacking is going to be a threat that will be with us for a couple of years, re:
http://jeremiahgrossman.blogspot.com/20 ... -2017.html
Now I stumbled upon the following info in some google cache of a page, as the info was no longer there online:
re: http://74.125.77.132/search?q=cache:Ia6 ... =firefox-a
As I do not know how long the cache info will remain there, hence I give you this info as I quote:

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.

[[0x000000.com]]

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.

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

What if the author is right in what he claims here (that NoScript does not protect against these specific forms of clickjacking), and is this a realistic threat now or in the future?
Waiting for your comments

luntrus

[mik33mik]

Hi,
this is very old. Giorgio has fixed this issue with NoScript version 1.8.1.9

Changelog:
http://noscript.net/changelog

v 1.8.1.9
+ Opacized objects are forced to a minimum size of 50x50 pixels
+ Opacized iframes get automatic scrollbars when content overflows
(thanks RSnake for discussion)
+ Enhanced legacy frames management (thanks RSnake for report)
x OBJECT elements embedding documents are treated like IFRAMEs
+ Improved Allow Page commands on pages changing document.domain

More info:
http://hackademix.net/2008/10/02/clickj ... y-default/

[luntrus]

Hi mik33mik,

I have found that out in the mean time, by reading somewhat more about these issues. Still the exact implications and the working scheme of this particular click jacking vulnerability is not known to us. More and more I have now discovered that NoScript is an omni-protection tool and absolutely vital to close the vulnerability window for the Firefox browser.
What I have seen here also is that these vulnerabilities should not only be tackled by the browser user with for instance in-browser security extensions like NoScript and RequestPolicy, but it is also mainly the responsibility of the website owners/admins/webmasters, that should not expose their visitors to mentioned threats.

There I still do not see a lot of activity in securing their pages. They seem to still have to be woken up to the new situation online.
What it is all about is concepts, so HTML injection, SQL injection and XSS are similar in this sense that the environmental syntax is being compromised (HTML-tags are being added, SQL-statements are being bent in certain respects, JavaScript is being added, obfuscated, etc.). Prevention of these attacks is being done in a similar way through prevention of third party's input breaking in on the syntax of constructed code. This is possible by changing certain characters (< by < in HTML, ' by \' in SQL) or using built-in functions that do this for you (htmlspecialchars() and mysql_real_escape_string() in PHP).

That knowledge is also applicable for securing against click-jacking exploits, and NoScript does this inside the browser.
Also the implementation of Content Security Policy (server-browser) could seriously make a difference,

luntrus