Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser auto-fill phishing

github.com

Post reply on HN
Print view View original

51–60 of 150 posts

Re: Browser auto-fill phishing

#51

Post by tiglionabbit »

alexwebb2 wrote: post #15
danso wrote: post #11

Wow, this seems like such an obvious attack vector that I just assumed it was somehow mitigated (somewhere, magically, I suppose). Does it even require the user to press the Submit button, i.e. could the site's JS trigger the POST request after the event of the autofill?

No need for a submit click. Presumably auto-fill triggers a change event on each affected input, but even if it didn't, an attacker could just repeatedly check for new content in the inputs. This means an optimistic solution (autofilling and then unobtrusively notifying the user what was autofilled) is not viable.

Notice that it's not checking the data with JavaScript. I was under the impression that there is already a security measure against this as far as JavaScript is concerned. The browser is already instructed to lie to JavaScript about certain details such as the :visited state of a link and any CSS rules that follow as a result of this.

Re: Browser auto-fill phishing

#53

Post by ajkjk »

jonknee wrote: post #21
athenot wrote: post #7

Earlier quoted context omitted.

The elements are not hidden, they are just drawn off the screen. So the browser would have to determine if the item is visible to the user, which is not trivial. Should autofill skip regular form elements that are just a little below the viewport? Maybe some feedback from the browser detailing which datapoints were autofilled. I don't know...

> So the browser would have to determine if the item is visible to the user, which is not trivial This is not terribly difficult, browsers need to know what is visible because they have to actually display it. If an element isn't drawn it shouldn't be autofilled.

What if another element is drawn in front of it, and though? I feel like there are a huge number of possible tricks to hide elements on page and trick the browser into thinking they're visible.

Re: Browser auto-fill phishing

#56

Post by takeda »

aesthetics1 wrote: post #2

Wow, great demonstration. I'd never thought about this being exploited. I wonder if the fix could be something as simple as the browser only allowing non-hidden [Edit: "not visible to the user", I should have said, as this does not appear to auto-fill ] fields to be auto-filled. Otherwise, a warning about what auto-fill information (IE "Your name and credit card information are going to be submitted, continue?") has…

I liked the old Opera approach to this. By default it did not fill the fields, unless you clicked on a Wand button, or used Ctrl+Enter shortcut.

This also worked really well with encrypted password storage (if you configured that key was forgotten after e.g. 10 minutes), it did not nag you to enter the password if you visited site where you stored password but did not intended to log in at given time.

There's an add-on for Firefox[1], but doesn't work as well as it did in Opera, and also it doesn't solve the password nagging issue, but I suppose it could help address the vulnerability mentioned here.

I really don't understand why all browsers insist to handle password this way.

[1] https://addons.mozilla.org/en-US/firefox/addon/secure-login/

Re: Browser auto-fill phishing

#57

Post by TheRealPomax »

Was this filed against Firefox, Chrome, and EDGE? (it seems like the kind of PoC that you make to prove a point to browser vendors to get them to fix what should obvioulsy be fixed... if the user can't see it, no matter how that's been achieved, don't autofill that field.)

Re: Browser auto-fill phishing

#58

Post by amenod »

FryHigh wrote: post #4

This vulnerability was published (another article) over a year ago. I'm surprised Chrome hasn't fixed it. I think this means browsers will never fix this issue. I won't be using auto-fill on untrusted webaites.

Not all browsers - Firefox suggests form input values one by one (when you click in the field) so it is not vulnerable AFAICT.

Re: Browser auto-fill phishing

#59

Post by ris »

jonknee wrote: post #21
athenot wrote: post #7

Earlier quoted context omitted.

The elements are not hidden, they are just drawn off the screen. So the browser would have to determine if the item is visible to the user, which is not trivial. Should autofill skip regular form elements that are just a little below the viewport? Maybe some feedback from the browser detailing which datapoints were autofilled. I don't know...

> So the browser would have to determine if the item is visible to the user, which is not trivial This is not terribly difficult, browsers need to know what is visible because they have to actually display it. If an element isn't drawn it shouldn't be autofilled.

Re: Browser auto-fill phishing

#60

Post by stevarino »

error54 wrote: post #8

In case anyone is worried, most (all?) browsers do not autofill credit card information without the user explicitly clicking into the credit card field so there's no chance of a hidden field stealing your CC information.

This requires the browser to recognize it as a credit card field.

Suppose a form uses a non-standard name for the field (say a localized name), and a user enters it at a legitimate site. Any attacker simply has to find these non-standard names for auto-complete to fill this in.

I feel like I've seen a credit card autofill before outside of normal controls.

Post reply on HN