Browser auto-fill phishing
121–130 of 150 posts
Re: Browser auto-fill phishing
#122Re: Browser auto-fill phishing
#123Earlier quoted context omitted.
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.
But then the browser won't autofill it, so what's the problem?
Re: Browser auto-fill phishing
#124Earlier quoted context omitted.
> If an element isn't drawn it shouldn't be autofilled. So if a form is too long and you need to scroll, all those fields you can't see won't be auto-filled? Sounds pretty terrible IMO.
Well why not have it autofill on-draw?
The solution to this problem is to inform the user which fields will be completed by autofill, with a "not currently shown" highlight on any fields that are currently off the screen so the user understands what's happening.
Re: Browser auto-fill phishing
#125This could be solved by improving the autofill UI to tell you all the data it is filling into the form, even if it isn't visible to you. Currently, when I trigger autofill in Chrome, it tells me the full suite of information it can input for a certain profile (name, address, company, etc), but it doesn't tell me which bits of information are actually being used. Something as simple as placing checkmarks in this popup…
Safari does this already
Re: Browser auto-fill phishing
#126I'd rather have only the field I selected autofilled and be given a secondary option to have every field (or maybe choose which fields) in a form autofilled. This bothers me in innocent, non-phishing forms too—especially when the designers don't put labels on the fields and only use placeholders, which I can no longer see after autofill.
Re: Browser auto-fill phishing
#127Earlier 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...
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.
Re: Browser auto-fill phishing
#128Earlier 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.
Re: Browser auto-fill phishing
#129Firefox doesn't exhibit this behavior, but the site doesn't specifically state which browsers this affects.
But Safari does it in the most elegant way. They show a popup with all the information that will be autofilled and ask you to confirm before filling out the fields which also protects against AJAXified submissions.
Re: Browser auto-fill phishing
#130I get 405 after submit.