document.cookie=null in circumstances involving signed.applets.codebase_principal_support




Security: CAPS
13 years ago
11 years ago


(Reporter: Izaak B., Assigned: dveditz)


Bug Flags:
blocking1.8b5 -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)





13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

when signed.applets.codebase_principal_support is true,
document.cookie returns null in whatever domains the user has told firefox to
'remember' special privileges. however, the cookies are still sent to the web

Reproducible: Always

Steps to Reproduce:
1. set 'signed.applets.codebase_principal_support' to 'true'
2. go to a domain that uses
3. ask firefox to 'remember' gained privileges
4. quit firefox and come back to the same domain

Actual Results:  
document.cookie always returns null in given domain

Expected Results:  
document.cookie should return cookies

Comment 1

13 years ago
so far i've tested this in linux and mac os x.
Version: unspecified → 1.0 Branch

Comment 2

13 years ago
-> Cookies
Assignee: nobody → darin
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: 1.0 Branch → 1.7 Branch
Worksforme on trunk....  Izaak, do you see this in a trunk build?
Never mind.  I've reproduced this.  The problem is that cookies (or more
precisely nsHTMLDocument::GetCookie) uses the URI in the principal as the URI
it's working with, and if you look at
nsScriptSecurityManager::GetCodebasePrincipal in the case when the principal
comes from the table we end up with a wrong URI (one that has no path on it, so
cookies fails the path security check and gives back no cookie).

So either cookies needs to use a different URI or the security manager needs to
always preserve the path in the codebase principal instead of sometimes
preserving it and sometimes not.  In fact, the latter should be fixed no matter
what; if we decide to never preserve the path instead, then we'll need to fix
GetCookie (and possibly other things) too.
Assignee: darin → dveditz
Component: Networking: Cookies → Security: CAPS
Ever confirmed: true
QA Contact: networking.cookies
Version: 1.7 Branch → Trunk
I think we should try to deal with this for 1.8; I'm not quite sure I can
exploit this yet, but I'll try to find a way.
Flags: blocking1.8b4?

Comment 6

13 years ago
principals are things we pass around for caps as a hook to the security policy
for that entity, they're really supposed to be mostly opaque to everyone else
(they're explicitly non-scriptable to keep unsavvy chrome author's hands off it).

Unfortunately having the codebase there is convenient, I bet there are a lot of
places that take advantage of this :-(

Comment 7

13 years ago
Doesn't appear to be a serious security issue - no known exploit.
Flags: blocking1.8b4? → blocking1.8b4-
Note that we need the codebase here for jar: channels, since using the document
URI there would be wrong.

Also note that the codebase is always "right" (includes path) for cert
principals; I just propose that codebase principals work the same way, cloning
the in-table cert as needed.
Note that we also use GetURI as the referrer in some cases...
One other reason to fix this -- various callers modify principals (eg SetDomain, some do SetURI, etc).  So we _really_ don't want to be sharing a principal between two different documents.  Which is where we are right now...
Fixed by checkin for bug 269270.
Last Resolved: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.