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.

confirming for discussion.

I didn't know HTTP redirects could go to non-http URLS...

They can!

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 ***

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.

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.

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!