Closed Bug 31650 Opened 25 years ago Closed 24 years ago

loading local files in a window

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: norrisboyd, Assigned: security-bugs)

References

(
URL
)

Details

(Whiteboard: [nsbeta2+])

Attachments

(2 files)

Testcase - try some variations on this testcase
(deleted), text/html
Details
the local file on the disk to run my test cases
(deleted), text/html
Details
Subject: Potential bug: loading local files in a window Date: Mon, 13 Mar 2000 16:06:50 +0200 From: Georgi Guninski <joro@nat.bg> To: Norris Boyd <norris@netscape.com> Generally, Mozilla disallows loading local files in a window (links, META refresh, HTTP redirects, forms, window.open). But it is possible to circumvent this using <A HREF="C:\file">C:\file</A> on Windows.
Status: NEW → ASSIGNED
Target Milestone: M15
Keywords: beta2
With no sign of progress... and Norris out this week... I'm pushing this to M16 to allow for the M15 branch.
Target Milestone: M15 → M16
Keywords: nsbeta2
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Hmm...I've never seen "c:\file" used as an URL before. I'll bet we're not checking URL's in this format correctly. Need to find a Windows machine to test this on. Should be an easy fix.
Status: NEW → ASSIGNED
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Blocks: 37425
Changed QA contact to Cathy.
QA Contact: junruh → czhang
I don't think this exploit works anymore. With a file called c:\Dupe.txt on my drive, I tried an <A HREF="..."> link tag with c:\Dupe.txt, c|\Dupe.txt, file:///c:\Dupe.txt, and file:///c|\Dupe.txt, and all of the above with forward slashes instead of backslashes. With file:/// present, the security manager stops the load, as it should. Without file:///, the load either fails immediately or attempts to prepend the base URL of the page containing the link. I'm marking this WORKSFORME. Cathy, could you please take another look? Start with the testcase HTML page which I'm abbout to attach here and try every weird syntax of C:\ or C|\ URL you can think of. You might also try putting these weird URL's in something besides an anchor tag - like a form, HTTP redirect, META refresh, etc. (see the original bug description).
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I don't find any way to access the local files, but there is new discover running meta refresh: http://cathyz/bugs/31650_meta_3.html, the browser automaticaly chop 31650_meta_3.html, displaying http://cathyz/bugs/, so the content of the fold are exposed. IE does not do this, it is not displaying anything, to run my test cases, create d:/javascript/test.html on your local disk, I attached test.html go to: http://cathyz/bugs/31650_link.html http://cathyz/bugs/31650_form.html http://cathyz/bugs/31650_window.html http://cathyz/bugs/31650_meta_1.html http://cathyz/bugs/31650_meta_2.html http://cathyz/bugs/31650_meta_3.html
I find the way to attack the local file http://cathyz/bugs/31650_base.html http://cathyz/bugs/31650_base_2.html http://cathyz/bugs/31650_base_3.html the code is: <html> <base href="file:///d|/javascript/"> <body> <a href="test.html">click here to see if you get the image, if you do, you are l oading local file, that is bad. </a> <p> </body></html> I think this bug is related with bug 35859. fixing either of them might fix both
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Fix checked in.
Status: REOPENED → ASSIGNED
Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
it is fixed
Status: RESOLVED → VERIFIED
Opening fixed security bugs to the public.
Group: netscapeconfidential?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: