Hacker News Reader

Comment by jonathonf | Hacker News Reader

It appears to be entirely foiled NoScript (i.e. Javascript whitelisting).

The proof of concept is foiled. But how about something similar like:

  <noscript>
    <meta http-equiv="refresh" content="600" 
    url="phish.php"> 
  </noscript>

I believe NoScript will pop up a message asking if you want to take the redirect, in that case.

I think you are right:

"Forbid META redirections inside <noscript> elements"

but then I immediately wondered, what about META redirections outside <noscript> elements? I tested this with a fresh install of Firefox and latest NoScript, and those still work. Also: To forbid meta redirections inside noscript elements you have to toggle an option, it's not standard for non-trusted sites.

Did you test the META redirection with a background tab? I'm pretty sure NoScript added an unconditional block of background redirects within a week or so of this attack being publicized.

Though NoScript is a security measure that 99.XX% of users do not use.

Not for me - I use NoScript and the only domain pre-enabled was googleapis.com. I haven't seen any change on the tab or the site.

I think parent was saying that the attack is foiled by NoScript, not that the attack foils NoScript.

Ah, it's a bit garbled and I read it the other way. Ta.

It's certainly that.

Make the initial site something that obviously needs javascript, and some percentage of NoScript users will enable it.

But that's already a big improvement, actually. With NoScript, if a site (not on the whitelist) has to run JS, the user will be consciously aware of it. Aside from the obvious benefits, NoScript, and other plugins like it, force the user to remember that the web is a potentially hostile place.

I'm sure it's an improvement; I'm not sure how big a one - that doubtless depends in part upon just what the NoScript user's habits look like.

Reply on news.ycombinator.com