The default bug view has changed. See this FAQ.

Server redirect to file:// disallowed response inadequate

VERIFIED DUPLICATE of bug 84128

Status

()

Core
Security
VERIFIED DUPLICATE of bug 84128
16 years ago
15 years ago

People

(Reporter: Kurt Swanson, Assigned: neeti)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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)

Updated

16 years ago
Depends on: 84128
confirming for discussion.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

16 years ago
I didn't know HTTP redirects could go to non-http URLS...
(Reporter)

Comment 3

16 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 5

16 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.

Comment 6

16 years ago
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.

Comment 8

16 years ago
I created a new bug for what kurt proposed in HTTP.
Status: RESOLVED → VERIFIED
Component: Networking → Security: General
QA Contact: benc → bsharma

Comment 9

15 years ago
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.