Open
Bug 906163
Opened 11 years ago
Updated 2 years ago
Form history used by extensions should be stored uniquely in Satchel
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
NEW
People
(Reporter: neil, Unassigned)
References
Details
(Keywords: csectype-disclosure, sec-want)
+++ This bug was initially created as a clone of Bug #461820 +++
I was asked to review a patch which used the form-history autocompletesearch component to add a history to a dialog field. Apparently this is already a common pattern used by several extensions including Fireftp, scrapbook and flickr-sidebar. As per bug 461820, the values entered in these extensions can be compromised in the same way that searchbar history could.
Is it actually safe for application chrome or extensions to be using the form-history autocompletesearch like this?
Comment 1•11 years ago
|
||
What part is unsafe? Maybe undesirable from a "you could get non-sensical results/unexpected data conflicts", but I don't see a security issue.
Comment 2•11 years ago
|
||
Unfortunately we "fixed" bug 461820 by blacklisting fields with a particular name which is fragile (we might change the XUL field name in the future) and, more to the point, means there isn't a generic mechanism addons can hook into to segregate their form data.
We should not hide this bug; instead we need to educate addon authors (and reviewers!) about the potential privacy issues that could come up. For some addons there will be no problem at all, and for others it will be a vulnerability specific to their addon.
Group: core-security
Keywords: csec-disclosure,
sec-want
Comment 3•11 years ago
|
||
So, we would want to ask developers to use a particular name for search fields, so that it doesn't use the main autocomplete storage?
Comment 4•11 years ago
|
||
Well they wouldn't all want to use the same name as then the form history from every add-on field will be mixed together. I guess we could use a prefix or something like that. It seems like there should be a better way to enforce this than naming but I haven't looked into that lately.
Comment 5•11 years ago
|
||
I don't think we should be lobbying add-on authors to work around this bug on their own unless there is a real security risk (which seems quite unlikely - bug 461820 wasn't that bad and was much more likely to result in conflicts in practice).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•