Comment by f- | Hacker News Reader

Comment by f- | Hacker News Reader

One important consideration here is that the phishing attack as described here could be pulled off even if the targeted site did not support redirects - and in general, it would be exploitable without any identifiable fault on the part of the "vulnerable" web app.

This property is an artifact of how browsers work, and it's not something that's likely to change soon. Basically, if you visit evil.com, evil.com can always load accounts.some-trusted-domain.com in a new window, give you enough time to examine the address bar and confirm that it's legit - and then sneakily navigate that window to a phishy location that looks the same as our legit login prompt, but is controlled by the attacker.

(The evil site can also detect certain events, such as navigation, and deliver the payload only at that point.)

For my whimsical demo for Chrome and Firefox (dating back to 2011!), see: http://lcamtuf.coredump.cx/switch/

(Disclaimer: I kinda wrote a book about this stuff. Also, I work for Google.)

I agree that you cannot 100% prevent phishing, but I think that the case presented here is slightly different: the "evil URL" is only contained in a parameter to an request to another URL. I don't think that the typical users will look at the things that come after the `?` in the URL, especially since those can be url-encoded an thus just look like garbage.

Couple notes:

1. You're talking about a pop-up / new tab that somebody clicked while already on an attack site...

2. then loading google.com in this pop-up / new tab and, waiting a few seconds, and then changing the location of the pop-up / new tab

The vulnerability in question consists of landing up on google.com, logging in while still on google.com, then google.com sending you directly to an attack site after you finish logging in.

The user could come from an official looking email (a known and largely unavoidable problem), or from a link that somebody pasted (e.g. "click here to view my spreadsheet on Google Sheets") into a comment on a different trusted site. The "trusted site" is important to note, because as you might have deduced, no scripts or malicious intent is required on the part of the other site; just a link. In your example, the other site would have to either A) be compromised itself, to facilitate the script, or B) malicious itself.

Which of the workflows would you be more likely to fall for, your example or mine?

Reply on news.ycombinator.com