Closed Bug 177988 Opened 19 years ago Closed 14 years ago
Storing persistent data (implicit cookie) with XUL
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.
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.
Status: NEW → ASSIGNED
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)? /be
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 http://www.xulchannels.com/ 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
Thanks for rescuing this needle from the obscurity of the haystack, Ben. Taking.
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
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.