Closed Bug 100067 Opened 23 years ago Closed 23 years ago

Frame does not render with specific src URL

Categories

(Core :: Security, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: tjohn, Assigned: security-bugs)

Details

Attachments

(1 file)

If a frame has the source URL of the form file://localhost/D|/SomeFile.html the
frame will not be rendered if the root document is not loaded via a file:// URL.
The WebObjects info center (part of WebObjects) for example will trigger this
behaviour.

This error occures with Mozilla build 2001091303 (0.9.4) on Windows 2000 with
service pack 2. I have not tested other platfroms.

Netscape 4.7x and Internet Explorer will render frames with such an URL correctly.

Bug reproduction:

Create a test.html in a webserver document root that contains

-- snip
<html>
<head>
<title>Test</title>
</head>
<frameset rows="*">
<frame src="file://localhost/C|/LocalDocument.html">
</frameset>
</html>
-- snip

Modify the frame source to point to a local file.
Open the test.html document via the webserver and the frame rendering will fail.
Open the test.html document via open file from the file menu and frame rendering
will work.
This worksforme on win98 and win2k, 2001102603.

Copied the html below to d:\inetpub\webroot\test.html and changed the reference
to "file://localhost/C|/LocalDocument.html" ... created the LocalDocument.html,
entered file://localhost/D|/InetPub/wwwroot/test.html into the location, and the
localdocument appeared properly ...

Reporter, can you please try to reproduce this on a more recent build and let us
know (within 10 days) if you're still seeing this behavior?

Thanks.
Tobias John, please don't put bug comments into attachments ... bug comments go
in the bug comments field :)

Reproducing here for the benefit of the average bugzilla user:

"It works if you specify a URL like
file://localhost/D|/InetPub/wwwroot/test.html in your address field.

What does not work is if you specify a URL like http://localhost/test.html
assuming, that the directory d:\InetPub\wwwroot is mapped to http://localhost/.

This works with IE and Nestcape 4.78. This is an issue if you have web
applications running on your local machine that acesses and displays local
documents that are not in the document root ofthe webserver serving the application.

An example for such an application is the WebObjects Info Center.
Maybe this is a bug of the application, since the application itself could serve
the document, but IE and Netscape 4.78 do not show this behaviour and I think
Mozilla should behave the same in this case.

(I think that this may be an access permission problem and at a first galnce I
can not see any security issues watching your own local documents)."

Personally, I'm not sure what the correct behavior is on this ... I can see on
both sides of the fence.  (Security issue/non-issue) ... I'll try to round up
someone to look at this.
Oops, forgot to mention that I -can- reproduce this.  Accessing the frameset
document via file:// will show the localdocument, but accessing it via http://
only shows a blank page.  (no error messages)
-> Security, I'm pretty sure this is a known issue
Assignee: pollmann → mstoltz
Component: HTMLFrames → Security: General
QA Contact: amar → bsharma
Please try adding this line to the prefs.js file in your user profile directory
(with Mozilla not running):
user_pref("security.checkloaduri", false);

Does that make the problem go away? It probably will. That will tell us whether
this is a CheckLoadURI problem, which it appears to be.
Yes.
Adding user_pref("security.checkloaduri", false); to the prefs.js will
wake the problem go away.
OK, this behavior is correct - a frameset document from the Web cannot load a
frame from file://. This prevents some security problems. If you need this to
work, set the pref I mentioned above.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Verified on
build: 2001-12-11-o3-Trunk
platform: Win NT

Tested both scenarios as mentioned above and the prefs setting. The test case
works fine.
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: