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

131–140 of 150 posts

Re: Browser auto-fill phishing

#131

Post by circular_logic »

hashhar wrote: post #128
theGimp wrote: post #65

Earlier quoted context omitted.

My thinking is the user should explicitly autofill each field. Yes, it involves more work, but it's really not much work to click on a field and pick the right autofill value. I'm always concerned about using autofill because browsers eagerly fill any field they have data for.

Firefox works that way and is in my view a much saner default. The best solution used to be in Opera long ago where they showed a little dropdown with the information that was going to be autofilled. You could accept it or deny it.

That sounds like a fantastic idea for an extention.

Re: Browser auto-fill phishing

#132

Post by PDoyle »

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.

How many pixels does an input need to occupy before it's considered "visible"?

Re: Browser auto-fill phishing

#133

Post by joantune »

joantune wrote: post #118

Yes! I always had this itch whenever I filled out a field and had the other fields pre filled by chrome. I actually thought that maybe there were type="hidden" that could have been filled and sent (although as someone points out those aren't but it isn't hard to hide an input with CSS). But the main point is: whenever I did that I was usually OK with sending out the rest of the information which either was outdated o…

PS: and/or like someone said that happens in Safari: name the fields that you are about to autofill in the last choice to autofill everything

Re: Browser auto-fill phishing

#134

Post by sytelus »

theGimp wrote: post #65
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...

My thinking is the user should explicitly autofill each field. Yes, it involves more work, but it's really not much work to click on a field and pick the right autofill value. I'm always concerned about using autofill because browsers eagerly fill any field they have data for.

That would be super bad user experience. Simple and better alternative would be to show everything being auto filled in page in a browser dialog and confirm from user before actually auto filling it.

Re: Browser auto-fill phishing

#135

Post by mbrookes »

bsimpson wrote: post #83
alexwebb2 wrote: post #15

Earlier quoted context omitted.

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.

I don't think it does trigger a change for exactly this reason. I tried to build a Material login page a couple years back, where the placeholder became the label when you typed. I couldn't get it to work with autofill, because I couldn't find a vector to detect when autofill had happened. Here's a related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=352527

That's correct - this has also been a massive issue for React, and still isn't fixed in a released version. There's a fix that was merged some time ago, pending release with React 16 [1]. There's some discussion about a 3rd party effort to back-port to 15.x.

[1] https://github.com/facebook/react/issues/7211#issuecomment-2...)

Re: Browser auto-fill phishing

#136

Post by talmand »

bored wrote: post #102
stabbles wrote: post #45

I wrote about this a while ago: https://medium.com/@stabbles/why-you-should-disable-autofill...

Also, malicious scripts can change the password input type field to a regular text field and grab it from there.

There's no need to convert the input type to get the plain text value of a password input. It just masks the input value visually.

Re: Browser auto-fill phishing

#137

Post by talmand »

grandalf wrote: post #78
hamhamed wrote: post #76

Earlier quoted context omitted.

It's disabled if you do autocomplete=off in the attributes

Not in my tests, it continued to aggressively populate forms with autocomplete="off" set.

That would be because that attribute is for a different feature of the browser. The autofill that this method takes advantage of is more of an extension beyond the standard browser feature.

Besides, someone using this for a phishing method wouldn't use that attribute anyway.

Re: Browser auto-fill phishing

#139

Post by tyingq »

bsimpson wrote: post #83
alexwebb2 wrote: post #15

Earlier quoted context omitted.

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.

I don't think it does trigger a change for exactly this reason. I tried to build a Material login page a couple years back, where the placeholder became the label when you typed. I couldn't get it to work with autofill, because I couldn't find a vector to detect when autofill had happened. Here's a related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=352527

It doesn't trigger a change, but you can certainly poll for non empty strings: https://jsfiddle.net/k91o1dw9/7/

Edit: That is, for the purposes of this exploit. I understand it's ugly.

Re: Browser auto-fill phishing

#140

Post by tyingq »

tiglionabbit wrote: post #51
alexwebb2 wrote: post #15

Earlier quoted context omitted.

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.

You can check the data with JavaScript if you poll. Try it out: https://jsfiddle.net/k91o1dw9/7/
Post reply on HN