Closed Bug 269270 Opened 20 years ago Closed 18 years ago

[FIX]Saved capability principal gives wrong baseURI for document.open() documents

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: drfoster, Assigned: bzbarsky)

References

Details

(Keywords: regression, Whiteboard: regressed by fix for bug 57600)

Attachments

(2 files)

Contains HTML files that demonstrate the problem
1.28 KB, application/x-zip-compressed
Details
Patch that fixes the attached testcase
12.62 KB, patch
dveditz
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I work on a web application that's Java servlet/JSP based. The web app accesses 
the clipboard of the browser's machine via JavaScript. In order to enable this, 
our users set "signed.applets.codebase_principal_support" to true 
in "about:config" and restart Firefox. When the JavaScript goes to access the 
clipboard, the user is asked about "enhanced abilities that are UNSAFE" and do 
they want to allow it. If they simply click "Allow", everything works. However, 
if they click "Remember this decision" followed by "Allow", the current access 
works, but if they shut down and restart their FireFox browser, the next access 
to the servlet (and every access from there on) generates 404 errors. The only 
way to make things work again is to shutdown Firefox, remove the "user_pref" 
settings for "capability.principal.codebase.pX.granted" (and the id) 
for "UniversalXPConnect" from the users prefs.js file and restart Firefox. 
After doing this, the user is prompted again about the "UNSAFE" action with 
every JavaScript clipboard access. 

I have duplicated this problem using Firefox 1.0 on both Windows (fully patched 
XP Pro/SP2) and Mac OSX (fully patched 10.3.6 on a PowerMac G5.) The problem 
does NOT occur using Mozilla 1.7 (on either platform), Camino 0.8 (on my Mac) 
or "some" previous builds of Firefox (I'm not sure how far back I have to go to 
see it work with Firefox, I went quite some time between the last build I 
downloaded (that worked) and version 1.0.) 

FYI: 

On Windows, Firefox's about says: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-
US; rv:1.7.5) Gecko/20041107 Firefox/1.0. 

On Mac OSX, Firefox's about says: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-
O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0. 


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
I have verified that this works correctly using "Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/
20040913 Firefox 0.10" on a SuSE 9.2 Linux machine.
can you post a sample application which shows this problem? and does it happen
in mozilla?
No, I don't have a way to make our web application available outside of our corporate firewall and as of 
yet, I've been unable to duplicate the problem with a generally accessible web site (application.)  I'm 
continuing to try to find one that exhibits the problem.

As I stated in my original bug report, this works fine with Mozilla 1.7 (Windows and Mac) and Camino 
0.8 (Mac.)  And, as my first follow up comment states, it also works fine with a Firefox 1.0 pre-pelease 
on a SuSE 9.2 Linux box.  I'm going to "downgrade" one of my Windows machines to the last Firefox 1.0 
pre-release I have to see if it works using that.

The error has got something to do with how Firefox has changed how user_pref's granting 
"UniversalXPConnect" privileges in the context of a web application is implemented.  Although my users 
get into this  state using the clipboard support from my web application, its got nothing to do with my 
clipboard support code.  If I simply add user_pref's granting "UniversalXPConnect" privileges to the 
address hosting an instance of our web app, that web app is no longer functional (although all others 
that DON'T have "UniversalXPConnect" privileges are.)  Removing these user_pref's lets the affected web 
app run again.

the only changes that would have been made between PR and final that would
affect this that I can think of are all security fixes.  If you can create a
test app that exhibits the problem, we can look at it then, but without knowing
what code is there its pretty hard to guess at the possible cause.
I "downgraded" my Firefox installation to "Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/
20040913 Firefox/0.10.1" and this works (i.e., it DOESN'T exhibit the problem.)  This is the most recent 
pre-release of Firefox I have available.  (Note that I allowed this version of Firefox to "patch" itself with 
the security patch when I first started it up.)

Going back to the 1.0 release of Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) 
Gecko/20041107 Firefox/1.0) causes the problem to return.  Clearly something "broke" regarding 
UniversalXPConnect very late in the game.

I'll continue testing and try to come up with a publicly accessible way to duplicate this.

I take it there's no easy way to review what changed with UniversalXPConnect between the pre-release 
and the 1.0 release.
sorry, by mozilla i meant the current version (grab a nightly), i did and do
read reports before commenting, so the question was meant to determine whether
the trunk was affected (it's not supposed to happen that ff1.0 and mozilla1.7.5
are out of sync, but it is the case, and a change for ff1.0 could conceivably be
on the trunk too).
Sorry, I didn't mean to imply you didn't read my inital report.  It was kind of wordy and I thought 
perhaps you just missed that point.

I downloaded the nightly build of Mozilla and it works fine (i.e., the issue I reported in Firefox is NOT 
there.)  Just to verify, its "About" says Mozilla 1.8a5 with the following description: "Mozilla/5.0 
(Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041112"

Ok, a little headway here.  Hopefully I can explain this clearly enough that it may be of some use to 
somebody :-)

I ran a sniffer as to what's going across the wire in both working and failure conditions.  When things 
are working, HTTP packets like the following are sent:

GET /nps/servlet/frameservice?NPService=fw.LaunchService&...more parameters...

When things are NOT working (i.e, when "UniversalXPConnect" is set), the HTTP packets contain the 
following:

GET /frameservice?NPService=fw.LaunchService&....more parameters....

Note that I'm clicking on the SAME link in the web application in both cases, in the first (with "/nps/
servlet/frameservice"), it works, in the later (where it's just "/frameservice") it doesn't.  Somewhere 
along the way, the "UniversalXPConnect" is causing the URL being submitted to be munged.

This ties in well with the 404 we're getting which is "The requested resource (/frameservice) is not 
available." (note the missing "/nps/servlet" in front of "/frameservice".)

Does this help?
Steps:
1. Expand the attached zip file into a temporary directory.
2. Bring up Firefox (the shipping version):
3. Goto "about:config".
4. If it's not already set, set "signed.applets.codebase_principal_support" to
"true".
5. Restart Firefox.
6. Open "index.html" from the directory the zip was expanded into in step 1.
7. Hover over the "Click here to test" link.  Note the target URL for the link
that gets displayed in the status bar.
8. Click the "Click here to test" link.  Note that "Success!" is displayed in
the right frame.
9. Click the "Click here to enable UniversalXPConnect..." link in the left
frame.
10. In the dialog, check the "Remember this decision" checkbox and press
"Allow".
11. Note the "You must now restart..." message and press Ok.
12. Restart Firefox.
13. Open the "index.html" file from the directory the zip was expanded into in
step 1 again.
14. Hover over the "Click here to test" link.  Note that the target URL
displayed in the status bar is NOT the same as it was in step 7 above.

*** THIS IS THE FAILURE.  THE URL'S SHOULD BE THE SAME ***

15. Note that if you click the "Click here to test" link, the link doesn't
work.  It's not working because relative URLs don't work in this situation when
UniversalXPConnect has been enabled on the connection.
Bummer!  Rather than seeing this problem get fixed in Firefox (which it hasn't yet), I now see that the 
bug has "migrated" to Mozilla itself (using version 1.7.5.)
"Firefox:OS Integration"? This is as clearly CAPS as anything.
Assignee: bugs → dveditz
Component: OS Integration → Security: CAPS
Product: Firefox → Core
QA Contact: os-integration
Version: unspecified → Trunk
Thanks for the testcase!
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a regression from bug 57600, which changed nsHTMLDocument::Open from
using the DocumentURI to using the CodebaseURI off the principal.

Most of the time this is identical because for documents that don't really have
a principal we just make one up containing the full URI so we have something to
compare against. But if a codebase principal was saved then if we encounter
pages from that site we give it the cached principal which has only the "origin"
(scheme+host+port) info.

I bet the results are worse if the saved principal were cert based.

Pincipals really ought to be opaque to everything except the security code. Do
we have more code trying to peek inside like this?

The originally proposed patch doesn't look like it would have this problem. The
trunk patch (which landed only recently) is somewhat different and I haven't
tested it yet. but it looks like it does the same thing.
Assignee: dveditz → jst
Component: Security: CAPS → DOM: Level 0
Keywords: regression
Summary: UniversalXPConnect Breaks Web Applications → Saved capability principal gives wrong baseURI for document.open() documents
Whiteboard: regressed by fix for bug 57600
nsContentAreaDragDrop.cpp: OK
nsFrameLoader: referrer could be wrong (just origin, or blank)
nsContentSink.cpp: OK (origin used to set cookies)
nsHTMLDocument.cpp: mostly OK except for this problem
nsDocShell.cpp: looks appropriate, but ValidateOrigin isn't using true
        document.domain -- is that just a signal for relaxed checking?
nsGlobalWindowImpl.cpp: OK
txMozillaStylesheetCompiler.cpp: looks OK
nsSchemaLoader.cpp::GetResolvedURI: has this same bug
nsWebScriptsAccess.cpp: OK
nsHTTPSOAPTransport.cpp: don't understand the use of the sourceURI sent to the  
        server. Does it have to be the real URI, or is it just a domain check?
        If the former it could be wrong as in this bug
nsWSDLLoader.cpp::GetResolvedURI: wrong as in this bug
nsDOMSerializer.cpp: ok (checkSameOrigin)
ProxyClassLoader.cpp: no idea what the Java factory needs. Probably OK.

What is happening with this bug? It is still a problem and we are forced to do some pretty ugly procedures to work around it.
We're relying on principals having useful URIs in a whole bunch of places now... we really need to fix this.
Flags: blocking1.9?
See for example bug 294689.  I'm just gonna post a patch, I guess.
Blocks: 294689
Should also fix bug 294689
Assignee: jst → bzbarsky
Status: NEW → ASSIGNED
Attachment #245879 - Flags: superreview?(jst)
Attachment #245879 - Flags: review?(dveditz)
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: Saved capability principal gives wrong baseURI for document.open() documents → [FIX]Saved capability principal gives wrong baseURI for document.open() documents
Target Milestone: --- → mozilla1.9alpha
Blocks: JEP/caps
Comment on attachment 245879 [details] [diff] [review]
Patch that fixes the attached testcase

r=dveditz
Attachment #245879 - Flags: review?(dveditz) → review+
Flags: blocking1.9? → blocking1.9+
Comment on attachment 245879 [details] [diff] [review]
Patch that fixes the attached testcase

sr=jst
Attachment #245879 - Flags: superreview?(jst) → superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
v.fixed Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: