Hacker News new | past | comments | ask | show | jobs | submit login

What's to stop the attacker from going the next step and forwarding the user/pass to Google, triggering the SMS for 2FA, and then prompting me to enter it?

Now all you can hope is that Google notices the source IP or user-agent of the attacker doesn't match up with the user's usual pattern.




Practically speaking, I think the attackers just focus on the 95% (or whatever percent it is) that don't have 2FA enabled. No reason to worry about the 5% who do.

This all changes if they are targeting a specific individual, or if one day everyone has 2FA enabled.


Can't they just disable forms that have the action attribute in forms pointed at anything other than google domain? i.e. a form with action="badbadsite.com/customfile.php" would be disabled.


If they use CSRF tokens, this wouldn't be possible.


I don't see how CSRF tokens apply here. They can login as you on another machine.


You did not read the parent comment. They cannot (or should not) be able to forward the login to Google's real form and trigger SMS 2FA because the real form should be protected by CSRF tokens.


No, CSRF isn't relevant. I'm an attacker and I have a server that's pretending to be a Google login form. I also have a client computer with a scripted browser pretending to be someone trying to login to Google. When you come to my page and login, I steal your data and immediately have my client program use it to login. If Google asks my client browser for a 2FA code, behind the scenes I forward that request to you and then when you answer, I forward the answer back to Google. From what Google can see, it just looks like someone logging in from a new computer.

None of this has anything to do with cross-site scripting. It's a MITM attack. CSRF doesn't come into play.


That's not what CSRF protects against and neither is it meant to. CSRF happens when you try to submit a form hosted on your site to a target site that the user has already authenticated to.

Here, the real form can be accessed from the attacker's browser, not the victim's, hence the attacker knows the CSRF tokens. CSRF doesn't protect against phishing.


I think the parent is theorizing that they could emulate someone logging in through their own headless browser to see if the credentials are valid, then if they are and the account has 2FA, they could trigger the SMS.


Exactly!

I'd assume there's CSRF on the login page, hence why I said: "hope ... Google notices the source IP or user-agent of the attacker"




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: