If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Wallet looks back too far for first field context (up to title)

RESOLVED WONTFIX

Status

()

Toolkit
Form Manager
--
major
RESOLVED WONTFIX
14 years ago
9 years ago

People

(Reporter: Jim Race, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
Using: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030827

To reproduce:

1) Open: http://www.thebulkclub.com/powerofnumbers.asp
2) In the form field labeled "# Emails Sent", highlight all chars and hit delete
3) Double click in the same form field

results: The users email address is pasted into the field

expected results: Nothing is pasted into the field. 

Now ignore the fact for a moment that this is a UCE vendors site. If I'm trying
to highlight all chars in a field by double clicking, I certainly don't want my
email address to be pasted into the field. If I accidentally submitted the form,
my email would be posted to the script for the form.

If this is a "works as designed", I *really* don't like it.
(Reporter)

Updated

14 years ago
Summary: Possible to leak email address unintentionally → Possible to leak email address unintentionally in form field
(Reporter)

Comment 1

14 years ago
Created attachment 130806 [details]
bulkmail_bug.html

Adding test case distilled from original bulkmail_bug.html

-jim
(Reporter)

Updated

14 years ago
Attachment #130806 - Attachment description: Distilled testcase → bulkmail_bug.html
(Reporter)

Comment 2

14 years ago
My bad. The instructions for the testcase weren't clear. To reproduce with the
above testcase:

1) Highlight all chars in the field labeled "test 1"
2) Hit delete
3) Double (or triple) click on the same blank form field

results: email address appears in form field.

expected results: Nothing is inserted into form field

Comment 3

14 years ago
Unable to reproduce with the latest trunk build on windows XP.

Comment 4

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031217

Confirmed. I see this as expected behaviour, and form fill tool is doing it's
job with double click on input box.

Comment 5

14 years ago
Yes.
Field is named Emails.
Form manager is invoked on doubleclick, fills out with what it has collected as
default Primary Contact email address. Disable form manager if this is a problem.

Form manager doesn't initially fill out because a default value exists.

Comment 6

14 years ago
Created attachment 137623 [details]
testcase, probably not quite minimal but close

Testcase seems to show bug dependent on the word email in the title and <input
type="text">

Comment 7

14 years ago
Ok, there's "email" in the page title of the first attached testcase. If you
remove this word from the title, it does NOT fill the field anymore.
Naming of the fields does not matter; I exchanged the first two fields and it
still filled the first one doing the equivalent steps, did not fill the second.

Possibly dangerous? If there is "credit card" or something in the title fields
might tend to be filled accordingly...

Comment 8

14 years ago
re my last comment 6 : The input type simply cannot be anything other than
text--if it's unspecified then the bug still appears.

Comment 9

14 years ago
Created attachment 137624 [details]
Minimal testcase

<html><head><title>email</title></head><body><input type="text"></body></html>
is all that is needed to reproduce the bug.
Attachment #130806 - Attachment is obsolete: true
Attachment #137623 - Attachment is obsolete: true

Comment 10

14 years ago
Oops, that last comment/testcase still has type="text" - it's unneeded, but
doesn't change the bug. Sorry for the spam.
It doesn't make sense for Form manager to reach all the way back to the title
for context in trying to fill the field, so it's a bug, but merely lame, not
evil. The original bulkmail page worked as intended since the word "email" was
gleaned in nearby context as the best guess.
(Reporter)

Comment 12

14 years ago
Happy holidays Dan... It's the twisted QA guy in me that is picturing a hidden
form field, a javascript event that duplicates a double-click, a long title that
doesn't show the form manager field in the title bar and a POST that scares me.

Not like that could happen. ;)

cheers,

-jim
(Reporter)

Comment 13

14 years ago
Created attachment 137681 [details]
Credit Card from Form Manager

This one pulls the Credit Card number if a user has one in Form Manager.
(Reporter)

Comment 14

14 years ago
To reproduce with the credit card attachment:
http://bugzilla.mozilla.org/attachment.cgi?id=137681&action=view

1) Add a fake credit card to Form Manager
2) Follow the steps in comment #2

results: Card Number is pasted into field.

Note that this example has a simple trick to "hide" the title info by adding a
long string of periods. I'm still playing with hidden form fields and
doubleclick events. I should get a real job. :/
Summary: Possible to leak email address unintentionally in form field → Possible to leak Form Manger data unintentionally
(Reporter)

Updated

14 years ago
OS: Windows 98 → Windows XP
Hardware: PC → All
Summary: Possible to leak Form Manger data unintentionally → Possible to leak Form Manager data unintentionally
Jim, <title> is a red herring: even assuming Form Manager didn't walk back as
far as the title a malicious page could still play games with you. Once you have
a form manager that fills fields without user confirmation using data originally
entered on another site we've got issues.

Leave aside ways you could fool the algorithm with text hidden in an invisible
<span> or in the title, a straightforward form correctly labelled with the data
the page wants exhibits all of the potential pitfalls here.

There is already bug 63320 to change the double-clicking behavior, which IMHO is
the user surprise and possible privacy leak issue. I'll modify this bug to cover
wallet looking back too far for context. I remember morse mentioning pages that
broke if he limited the context to the form itself, but surely we can think of
some better limit than reaching all the way back into the <title>
Summary: Possible to leak Form Manager data unintentionally → Wallet looks back too far for first field context (up to title)

Comment 16

14 years ago
This would mainly be dangerous with hidden form fields where the user doesn't
see what he (erm..: Mozilla) entered. But I guess there is nothing entered
without double clicking the field. Or did you have any success when trying such
a thing, Jim? E.g. with Javascript triggering a click event or something?
Does form manager touch hidden fields at all?

However, maybe some bad things could be done with non-hidden, but very small
fields, or with ones covered by other elements (e.g. <div>s). Can
text/backgroung colors of form fields be changed (I'm too lazy to look it up
myself, just writing down thoughts...).
(Reporter)

Comment 17

14 years ago
Andreas, I haven't yet been able to successfully add wallet data to a hidden
form field via a doubleclick (onclick="doubleclickVar.onClick()) type event but
I'm no coder, just a QA guy. My tests to date have been with something akin to a
"this paged has moved, click here to continue" that triggers a double-click.

I do agree with Dan that the whole double-click deal has many rather thought
provoking (and touchy) issues after reading bug 63320. The unfortunate thing is
that bug has had no movement in some time. I just worry a bit that this might be
something latent no one has exploited yet. That being said, Dan was far more
level headed than I when I worked with him at NSCP, so I'll defer to his judgement.
Andreas: Wallet explicitly skips hidden fields -- no worries there. First
there's the obvious privacy issues of sending information the user hasn't seen
or approved, and second, since wallet is intended to help people it should only
do what a user could do and a user can't fill a hidden field.

Thanks for the kind words, Jim. I'm more of a "stuckee" than an owner for Form
and Password manager so I'm not sure I'll be able to help much here. I do,
however, find myself with a bit more time on my hands than I expected,
unfortunately.
Assignee: dveditz → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: tpreston → form-manager

Updated

9 years ago
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: form-manager → form.manager
Version: 1.4 Branch → unspecified
Wallet is dead, and password manager does not have this problem.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.