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 server. Reproducible: Always Steps to Reproduce: 1. set 'signed.applets.codebase_principal_support' to 'true' 2. go to a domain that uses netscape.security.PrivilegeManager 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
so far i've tested this in linux and mac os x.
Version: unspecified → 1.0 Branch
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
Status: UNCONFIRMED → NEW
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.
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 :-(
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...
11 years ago
Depends on: 269270
Fixed by checkin for bug 269270.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.