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?
Browser auto-fill phishing
11–20 of 150 posts
Re: Browser auto-fill phishing
#12Wow, 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…
Only allowing non-(display:none) fields wouldn't be enough. You could still position them off screen, or behind an image, or very small or nearly transparent, or any other sneaky tactic. Your second idea about an auto-fill warning would be better. Maybe a simple footer warning or something.
I guess I did not think about offscreen or otherwise sneakily positioned form elements. I think the warning is the best way to handle this. I imagine it being something similar to an android permissions popup, where you can check off what should be "shared" (auto-filled) with the site before actually populating the form.
Re: Browser auto-fill phishing
#13Wow, 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…
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...
In Safari, the autofill dropdown explicitly said it would fill "email, work, address" (and I guess it implies that name is included).
Re: Browser auto-fill phishing
#14[deleted]
Re: Browser auto-fill phishing
#15Wow, 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.
Re: Browser auto-fill phishing
#16Wow, 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?
Yup, you could AJAX-ily listen to the phish fields
Re: Browser auto-fill phishing
#17Earlier 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...
In Safari, the autofill dropdown explicitly said it would fill "email, work, address" (and I guess it implies that name is included).
How obvious is this to the user? This seems like a detail that'd be easily overlooked.
Re: Browser auto-fill phishing
#18LastPass prompts every time before autofilling your CC# into a form, so it might avoid this issue in that case.
I do believe it would still fail exposing your basic info, such as in this example, however.
Re: Browser auto-fill phishing
#19Complete tangent but... why is this a NPM package? There is no actual Javascript code in it.
Re: Browser auto-fill phishing
#20Earlier quoted context omitted.
Only allowing non-(display:none) fields wouldn't be enough. You could still position them off screen, or behind an image, or very small or nearly transparent, or any other sneaky tactic. Your second idea about an auto-fill warning would be better. Maybe a simple footer warning or something.
I guess I did not think about offscreen or otherwise sneakily positioned form elements. I think the warning is the best way to handle this. I imagine it being something similar to an android permissions popup, where you can check off what should be "shared" (auto-filled) with the site before actually populating the form.
Then you'll love this concept: https://www.youtube.com/watch?v=3mk0RySeNsU A 1:18 "clickjacking" demo. (Link to video because I think this is legitimately one of those cases where a video can describe and demonstrate the problem faster than text.) You can google around for more info, or at least my YouTube is definitely popping up some other relevant videos.