InformAction Forums

therube wrote: A happy camper here

accessibility.blockautorefresh looks to be working in a current <SeaMonkey> Trunk.

...

Hmm. Now maybe we could use a little more fine grained control .
Anyhow, it makes me just that little bit more in control over Bank of America.

http://forums.mozillazine.org/viewtopic ... 5#p9309545

therube wrote:

NoScript actually deferred the refresh until the tab gets selected again

But then wouldn't that allow the refresh even on pages where you do not want it too?

Yes, but there are other means to block refresh unconditionally (built-in in Firefox).

therube wrote:

NoScript actually deferred the refresh until the tab gets selected again

But then wouldn't that allow the refresh even on pages where you do not want it too?

I agree. This doesn't seem to mitigate the exploit.

I do want to keep the current behavior where whitelisted or excepted sites continue to be reloaded even while they're in the background. I currently use RefreshBlocker to block that by default and use its whitelist on a few sites.

Giorgio Maone wrote:

therube wrote: But ... thinking that whitelisting may still be a hassle, might not be a desired approach?

I'm actually planning an easier way:

1. Replacing the built-in Firefox notification with one provided by NoScript like the "Forbid META inside NOSCRIPT" one (so Seamonkey 2.x users get the notification as well)
2. Having two buttons in the notification, "Follow" and "Always Follow", the latter of which adds the 2nd level domain to the exceptions pattern.

I prefer this approach.

Alan Baxter wrote:

therube wrote:

NoScript actually deferred the refresh until the tab gets selected again

But then wouldn't that allow the refresh even on pages where you do not want it too?

I agree. This doesn't seem to mitigate the exploit.

It does mitigate the exploit at hand because the refresh would never happen "while you're not looking at the page", and you couldn't be fooled into clicking the tab believing it's a different site.
[EDIT]
Furthermore, while I'm testing this approach, I noticed that since the attacker (at least in Aviv Raff's PoC) goes to great lengths to make the phishing refresh happen only when you're not looking at the page, that "malicious" refresh just never happens. So long for tabnabbing. A generic refresh blocking feature with whitelists and all is a different matter, which may or may not be worth a NoScript feature (since alternatives exist, AFAIK).

To me, the issue is confusing enough. Even seeing it happen & realizing what is happening would still be confusing. Much less to those unfamiliar.

So if the purpose is to block a refresh, then do it.

Cause seeing something happen & understanding what you are seeing could be two different things.

therube wrote: So if the purpose is to block a refresh, then do it.

See my EDIT above. If there's malicious intent and tries to conceal itself (like in Aviv Raff's case), the refresh just doesn't happen.
On the other hand, if the page refreshes unconditionally in the open (which hardly qualifies as an attack), you need a different countermeasure and even 1.9.9.81 as it is can't help: you need to block every refresh (eve those happening in front of your eyes), and you already have means to do it (in Firefox at least).

Giorgio Maone wrote:It does mitigate the exploit at hand because the refresh would never happen "while you're not looking at the page", and you couldn't be fooled into clicking the tab believing it's a different site.

OK. I see what you mean now. BTW, some people browse their tabs with Ctrl+PgUp/PgDn and don't go by the tab title or favicon (which may be so small as to be unreadable anyhow). I suppose seeing some unrelated site refresh itself to a gmail page right in front of my eyes would cause a WTF moment for me and I wouldn't trust the result. (Assuming I'm looking at the page while switching to it.)

[EDIT]
Furthermore, while I'm testing this approach, I noticed that since the attacker (at least in Aviv Raff's PoC) goes to great lengths to make the phishing refresh happen only when you're not looking at the page, that "malicious" refresh just never happens. So long for tabnabbing. A generic refresh blocking feature with whitelists and all is a different matter, which may or may not be worth a NoScript feature (since alternatives exist, AFAIK).

I suspect my use of RefreshBlocker may prevent tabnapping from happening on a non-whitelisted site anyhow. Since I have sites blacklisted by default in RefreshBlocker, it's obvious that clicking through a notification bar isn't too disturbing for me. Thank goodness RefreshBlocker supports whitelisting though.

(Assuming I'm looking at the page while switching to it.)

That could be a big assumption for some (myself included).

Please check latest development build. It seems quite effective against tabnabbing, while not getting in your way when refreshes are legit (they automatically happen after the tab is kept in focus for one second).