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

141–150 of 150 posts

Re: Browser auto-fill phishing

#141

Post by tyingq »

Ajedi32 wrote: post #49
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…

> Otherwise, a warning about what auto-fill information (IE "Your name and credit card information are going to be submitted, continue?") FYI this doesn't work for credit card info, at least not in Chrome. That information has to be auto-filled separately.

It does "sort of" work on Chrome. It does give the end user a visual cue when typing in a name...the last 4 and the cc logo: http://i.imgur.com/2bY2Pes.png

But, if the end user doesn't notice or care about the visual cue, you can exploit it. Start typing in a name that has a credit card associated with it in Chrome's autofill: https://jsfiddle.net/hvs4ox2q/4/

Re: Browser auto-fill phishing

#142

Post by tyingq »

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.

Chrome does autofill CC info based on just a name if you want. It does give the user a visual cue as to what might happen http://i.imgur.com/2bY2Pes.png

You might catch some careless people with it though: https://jsfiddle.net/hvs4ox2q/4/

Re: Browser auto-fill phishing

#143

Post by EJTH »

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.

Problem is that a form might be longer or wider than the viewport, which would result in "hidden" elements in genuine browsers too.

Re: Browser auto-fill phishing

#144

Post by cbr »

ksenzee wrote: post #91
cbr wrote: post #72

Earlier quoted context omitted.

your password manager's url comparison? Better than manual url comparision! A surprising number of humans think things like www.goodcompany.evil.com are urls for "Good Company", and anyone can screw up and make mistakes checking urls (www.goodcomany.com).

Add Unicode and it gets worse. I don't trust my eyes to differentiate between Cyrillic а and Latin a. https://en.wikipedia.org/wiki/IDN_homograph_attack

Browsers only display unicode in domain names if the TLD has restrictions on character sets that prevent homograph attacks.

See https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending...

Re: Browser auto-fill phishing

#146

Post by TheRealPomax »

lucb1e wrote: post #120
TheRealPomax wrote: post #57

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.)

Firefox is not vulnerable. Chrome was shown to be vulnerable like 7 years ago but nothing changed. Closed source stuff like MSIE or Safari? No idea, ask a Windows os OS X user.

MS EDGE, unlike the now hopelessly outdated Internet Explorer, has an open issue tracker. And as Safari is literally just webkit, which also has an open issue tracker, there was no need to pretend to be better than Windows and OSX users by pretending they're on their own.

Re: Browser auto-fill phishing

#147

Post by avodonosov »

ycmbntrthrwaway wrote: post #111
avodonosov wrote: post #105

And Chrome wants to ignore autocomplete=off ( https://news.ycombinator.com/item?id=11911116 )

Why not? Anyone who wants to steal your information would not try to disable autocomplete anyway.

You're right, following standard in regard to autocomplete=off will not prevent this attack.

I think I remembered of that because the direction of though that autocomplete should always be enabled appears as wrong to me. And this situation reminded me of this direction of though in the past case.

Re: Browser auto-fill phishing

#150

Post by itissid »

ycmbntrthrwaway wrote: post #109
jaxomlotus wrote: post #42

Earlier quoted context omitted.

Another method would be to show a user a list of all fields that are about to be filled in as part of the autocomplete prompt. This isn't very scalable for massive forms, but should be enough of an alert to a user that something is amiss on screen to make up for those cases.

You can scale it by classifying fields into groups. Then user can decide gradually if he wants to share his name. Later, application may ask for location (browsers can already do this), employer info, contact data etc. What is needed is integration with permission granting mechanisms, which already exist in browsers.

Actually this problem looks is a lot like how Android App permissions are managed. Not long ago some apps used to ask you at install time that they want access to your google email, contacts, wifi and so on. A better app permission model (which I think is now in android) is to ask these "lazily" as the app needs them and let the user decide at that point.
Post reply on HN