RFE: "Block all from Untrusted" should block IFrames and ALL

[Tom T.]

(from viewtopic.php?p=13798#p13798)

Fx 3.5.5
NS 1.9.9.18
RP 0.5.12
RefControl 0.8.13

http://michaelx1974.blogspot.com/

RP: Allow requests from blogspot.com to infosniper.net.
NS Embeddings: Uncheck "Forbid IFRAME", all others checked, specifically "Block every object from a site marked as untrusted".
NS: Allow infosniper.net.

Result: infosniper object displays user's location (upper left under "Welcome").

NS: Mark infosniper as Untrusted; reload page.

Expected result: Object should disappear on reload.
Actual result: Object remains and displays user location as above.

Bug: "Block every object from a site marked as untrusted" does not override the allowance of IFrame as it is supposed to.
Suggested fix: "Block every ... untrusted" should include blocking IFrames from sites marked as Untrusted.

[Giorgio Maone]

An IFrame does not qualify as an "Object" (i.e. active embeddings like applets and plugin content): it's just a document.
More specifically, an IFrame which cannot execute any active code (like it happens for untrusted IFrames when "Block every object" is checked) can't do any harm.

[al_9x]

What did you mean here then:

Actually the only thing missing in document, image and stylesheet blocking, because plugin and frame blocking is automatically applied to untrusted sites independently from the other settings.

It's somewhat confusing because the option refers to all objects which are partially enumerated above it and IFRAME is among them.

But regardless whether this is a bug or not, can you expand that setting to optionally include everything? When I mark a site untrusted, I don't want any third party contact with it. Yes, RP can do this, but you're are already more than half way there.

[Tom T.]

Concur with al_9x, referring to viewtopic.php?p=1257#p1257

<snip> plugin and frame blocking is automatically applied to untrusted sites independently from the other settings.

This is what I thought, too, and this is why I thought IFrame would be blocked from untrusted sites. Yet infosniper IFrame was not blocked when infosniper was untrusted.

In any case, if this is not a bug, I'd like to make it a RFE. (al_9x, do you concur/support?) Should I change the title of this thread from "BUG" to "RFE", or start a new thread and refer to this one? Thanks.

[GµårÐïåñ]

I am not sure but I believe that Giorgio is actually consistent in what he has said and is saying now but the difference is that NoScript evaluates for threats and if the iFrame doesn't have any object within it that are considered a threat, by itself its just another HTML tag, so no harm in using it. Only when its embedded to do harm, will it be considered a bad object to be blocked. I am hoping that this is what he is tryign to explain and this will lend a small hand to clarify that "discrepancy" if you will. This is just my humble opinion and I apologize to all if I am off the mark with my understanding of what Giorgio has told me in the past. I am sure he can clarify and correct me if I am wrong, thanks.

[Tom T.]

I am not sure but I believe that Giorgio is actually consistent in what he has said and is saying now but the difference is that NoScript evaluates for threats and if the iFrame doesn't have any object within it that are considered a threat, by itself its just another HTML tag, so no harm in using it. Only when its embedded to do harm, will it be considered a bad object to be blocked. I am hoping that this is what he is tryign to explain and this will lend a small hand to clarify that "discrepancy" if you will. This is just my humble opinion and I apologize to all if I am off the mark with my understanding of what Giorgio has told me in the past. I am sure he can clarify and correct me if I am wrong, thanks.

Yes, I believe that you are correct and that that is what Giorgio is saying. However, it seems counter-intuitive, IMHO; al_9x, myself, and many others, probably, believed that when we marked a site as Untrusted, we would avoid all contact with it, saying, in effect, "Don't even touch me!"

(Incidentally, how does infosniper parse my IP into a location without executing *some* sort of code?)

Nevertheless, it is still a waste of my bandwidth and resources to load and display *anything* from a site I don't trust, even if no "harm" can come of it.

viewtopic.php?p=1254#p1254
April 5, 2009

I asked about this on the old forum but I don't think you responded, what do you think? If a domain is untrusted there is no reason to give them anything or get and parse anything from them. <snip>

Put in my TODO list, thanks for the suggestion.<snip>

@ Giorgio: Is there any reason why this was removed from the TODO list?

Comments from others regarding the request to block ALL from Untrusted sites?

[GµårÐïåñ]

Often, although not always, the IP is gleamed from the header you are sending by simply accessing it, its not actually pinging you, although that method is more reliable to avoid spoofing and NS actually has a function to prevent/allow pinging. However, even then there are other ways to request the connection information from the server that is processing you (server side ping) and further you can even grab it from the gateway or proxy that is serving your connection. Not a huge bandwidth hog, but none the less I understand your concern.

As for the other issue, if NS were to arbitrarily block legitimate HTML tags, it would cripple the rendering of the site and that's a bad thing. As long as the iFrame is not executing something or linking to some payload or whatever, it is just another HTML tag and nothing more, blocking it makes no sense. The upside of NS blocking functionality is that, IF someone is trying to hide a malicious or even invasive code that is not malicious inside an iFrame or near invisible frame, it will render it ineffective and will cripple it until stated otherwise. This concept I have no issue with, my issue which I won't drag into THIS discussion was that when a site is marked as untrusted, treat IT and all its sub-components as such instead of making them pending independent objects. The concept of inheritance of permission if you want to think of it that way, if the parent is marked as bad by ME, then treat ALL of it as bad, instead of separating the object permissions on their own.

[Tom T.]

As for the other issue, if NS were to arbitrarily block legitimate HTML tags, it would cripple the rendering of the site and that's a bad thing.

How does blocking the HTML tag <iframe> </iframe> break the page if the contents of the source of the iframe aren't going to be loaded anyway?

As long as the iFrame is not executing something or linking to some payload or whatever, it is just another HTML tag and nothing more, blocking it makes no sense.

How was the infosniper object not linking to something or not executing something, if it could display the location?

The upside of NS blocking functionality is that, IF someone is trying to hide a malicious or even invasive code that is not malicious inside an iFrame or near invisible frame, it will render it ineffective and will cripple it until stated otherwise.

It did not render the infosniper object ineffective.

... my issue which I won't drag into THIS discussion was that when a site is marked as untrusted, treat IT and all its sub-components as such instead of making them pending independent objects.

Bingo, ditto. That's exactly what I said above. I marked infosniper.net as Untrusted, yet its whatever ran with the little flag and location display.

The concept of inheritance of permission if you want to think of it that way, if the parent is marked as bad by ME, then treat ALL of it as bad, instead of separating the object permissions on their own.

Ditto again. Infosniper.net was marked as bad by ME, so I'd like ALL of it to be treated as bad. I think we're advocating pretty much the same result, though perhaps in different words.

[al_9x]

if NS were to arbitrarily block legitimate HTML tags, it would cripple the rendering of the site

That is a straw man and not an adequate description of what is being proposed. The proposal is to optionally block third party requests to untrusted sites, for convenience, privacy, and even security reasons.

1) Convenience: I don't want to see any content from a third party untrusted site. Although not a security feature, still very useful and well within reach.
2) Privacy: I see no reason to send any info to an untrusted site, as can be done even with urls.
3) Security: I see no reason to parse and render anything from an untrusted site, including images, html and css. The chances of an exploitable image/css/html parsing/rendering bug are small but not 0. I am not suggesting to fear html, css and images, but from untrusted sites might as well avoid them.
4) Since this would be opt in, anyone who doesn't care or actually wants to continue to interact with untrusted sites, will not be impacted

[GµårÐïåñ]

I am confident that anyone looking our statements can see that we are all in agreement to the problem; we are just coming at it from different perspectives that are primary concern to us individually. Ultimately, we all want the same thing, just for different reasons.