Closed Bug 177988 Opened 19 years ago Closed 14 years ago

Storing persistent data (implicit cookie) with XUL


(Core :: Security, defect)

Not set





(Reporter: security-bugs, Assigned: dveditz)


(Depends on 1 open bug)


(Keywords: privacy)


(1 file)

There is a small privacy issue with XUL and persistance.
Even if cookies are disabled (but js enabled, it is possible to store
persistent information on the user's browser thru XUL's document.persist().
Attached file persist1.xul demonstrates the persistance - enter some text,
click remember, close the browser, visit the page again, result - the text
is remembered.
Attached file Example: persist1.xul
Here is Georgi's example.
It looks like only the page that set this XUL "cookie" could read the value back
(not a cross site hole).  Is this correct?
Can we make the XUL document function |persist()| inaccessible by XUL pages on
the Web (make it chrome-only?) If so, I'll do that. If doing so would break many
pages or Web apps, then I'm going to wontfix this, since the privacy violation
is minor.
How do you propose to find out whether any remote XUL app would be broken? 
Maybe find all the remote XUL apps known to the community and to google, and
test them.  That sounds hard, and likely to produce positives.  I'd say WONTFIX
now, save time ;-).

Or, how about making persist() fail if cookies are disabled for the site that
served the .xul page that calls persist (or disabled globally)?

Is there any way for the user to see, from the browser, that this "cookie" has
been set? Is there any way to delete it from the browser? If the answer to
either of these questions is "no", then I don't think this should be wontfixed
(and I suspect the answer is "no" to both).

We are very concened about cookies, and some people are practically paranoid
about them. Consequently we have pretty amazing controls for cookies. That
should be our cue that anything that offers similar functionality should be
dealt with the same care. 

At a minimum there should be a hidden pref to turn this feature off for remote
XUL. Enabling/disabling based on your cookie settings seems almost reasonable,
the biggest trouble IMO being that if you first enable and then disable a site,
it may have set something in the meanwhile that you do not know about and can
not get rid of (as I assumed in the first paragraph). Could these persistent
settings be cleared when you clear cache, cookies, history, or something?

I would suggest checking a collection of XUL apps from mozdev and seeing if they
use this feature. I wouldn't go so far as to try and test every XUL app you can
find. If you know of any app that actually does remember settings, they should
be naturally checked. One thing that comes to mind is the XUL-based
newsaggegator at where you can add a channel,
although I don't know if that affects all users or just you. Asking a few
knowledgeable XUL developers might give a fast answer as well...
Also, another way to disable this for remote content would be to fail without
throwing and only post a warning to the JS console. I think that would be most
likely to not break any existing apps.
Sorry, I am a bit slow today... I think we already "have a hidden pref" solution
by making document.persist noAccess. I hope that works for XUL docs as well... 
This makes all of our cookie prefs and managers useless, in theory. Thus
severity major.
Severity: normal → major
Keywords: privacy
Thanks for rescuing this needle from the obscurity of the haystack, Ben. Taking.
Assignee: security-bugs → dveditz
OS: Windows 2000 → All
Hardware: PC → All
Please note:

1) document.persist() is not the only way this happens. Adding a
persist="attributename,attributename2" to any element with an ID will persist
that attribute in the localstore.

2) This is an important part of ordinary remote-XUL applications and should not
be unconditionally turned off. Use the cookie preferences as appropriate, and
perhaps add a "localstore-cleansing" mechanism if somebody clears cookies.
Yes I should have mentioned that... only controlling script access to the
persist property wouldn't work. And yes, persist is a useful and legitimate part
of a web application.

This will have to depend on the UniversalPhishing privs bug rather than invent
yet another mechanism or list of privileges.
Depends on: universalphishing
Dup of bug 295994?
With Bug #144795, disallowing persist would render remote xul applications into
a useless state, because there is no way to store anything on the client side.
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2008-5505
You need to log in before you can comment on or make changes to this bug.