Closed
Bug 101207
Opened 23 years ago
Closed 23 years ago
Server redirect to file:// disallowed response inadequate
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
People
(Reporter: mozspam4kurt, Assigned: neeti)
References
(Depends on 1 open bug, )
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 BuildID: 20001091323 When security disallows file:// URLs Reproducible: Always Steps to Reproduce: 1. Ensure that security.checkloaduri is true (this is the default) 2. Go to http://kswanson.com/redirect-example.html Actual Results: The server's redirect html is simply displayed as a normal html page. Expected Results: Either follow the link, or produce a security warning to the user. This bug is the result of a discussion of bug 84128. Note that the security concerns discussed in bug 84128 do not apply to this situation, as the server has no means of knowing the result of the redirection it responded with.
Reporter | ||
Comment 3•23 years ago
|
||
They can!
Comment 4•23 years ago
|
||
Kurt, the same security concerns apply in this case. As I've explained before in other bugs, the server doesn't need to be able to read the result of the load to cause damage. On some Win98 systems, loading file:///C:/con/con causes a crash and data loss. Similar results could come from accessing something in file:///dev/* on Unix, and I believe similar problems exist on Mac as well. Also, if an attacker can cause content to be placed on the user's hard drive, for example by setting a cookie, stuffing the cache, etc., and can cause that content to execute in the browser, then that content can communicate information back to the attacker, one way or another. The contents of the user profile directory are also protected by the directory path salting, but in this case we have two levels of protection. This is called "defense in depth," or as Jim Roskind calls it, "belt and suspenders." I will put up a web page explaining the CheckLaodURI policy and its reasoning soon. In the meantime, this is the same issue as 84128 - a user-visible message when CheckLoadURI fails. We can continue the discussion there, or better yet in the newsgroup (netscape.public.mozilla.security). I am not opposed to adding some sort of user-visible notification that CheckLoadURI has failed, if we can come up with a good means of notification (NOT a dialog). I'm just tired of people insisting there's no security concern. I assure you there is - and it has bitten us before. *** This bug has been marked as a duplicate of 84128 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•23 years ago
|
||
Mitchell, I opened this bug on Benjamin's request. I have no objection to merging this into 84128, however, as long as this separate but related issue is addressed.
I was thinking that we shouldn't allow HTTP redirects to point to anything other than http: URLs... I've asked some people if redirects to non-http URLs are legal, and nobody has said so for sure. Does anyone know from a definitive standpoint? if so, this isn't really a dupe, b/c HTTP should cut this off.
Comment 7•23 years ago
|
||
Ben, If that's the case, then IMHO it's a separate bug. This bug is about informing the user, which is the same issue as 84128.
I created a new bug for what kurt proposed in HTTP.
Status: RESOLVED → VERIFIED
Component: Networking → Security: General
QA Contact: benc → bsharma
Bug 102262. Had alot of trouble finding it today. I'll never file a new bug w/o putting a ref into the old bug. I promise!
You need to log in
before you can comment on or make changes to this bug.
Description
•