Closed Bug 218153 Opened 22 years ago Closed 17 years ago

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

Categories

(Toolkit :: Form Manager, defect)

Product:
Toolkit
Component:
Form Manager
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: vimages, Unassigned)

References

(
URL
)

Details

Attachments

(2 files, 2 obsolete files)

Minimal testcase
79 bytes, text/html
Details
Credit Card from Form Manager
439 bytes, text/html
Details
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.
Summary: Possible to leak email address unintentionally → Possible to leak email address unintentionally in form field
Attached file bulkmail_bug.html (obsolete) —
Adding test case distilled from original bulkmail_bug.html -jim
Attachment #130806 - Attachment description: Distilled testcase → bulkmail_bug.html
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
Unable to reproduce with the latest trunk build on windows XP.
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.
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.
Testcase seems to show bug dependent on the word email in the title and <input type="text">
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...
re my last comment 6 : The input type simply cannot be anything other than text--if it's unspecified then the bug still appears.
Attached file 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
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.
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
This one pulls the Credit Card number if a user has one in Form Manager.
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
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)
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...).
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
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
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: