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)

defect

Tracking

()

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?
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.
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
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?
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.
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).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.