Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[FIX] Can't redirect to data: urls

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Networking: HTTP
P1
normal
RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

(Depends on: 1 bug)

Trunk
mozilla1.9alpha1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

1.30 KB, patch
Jesse Ruderman
: review+
dveditz
: review+
Darin Fisher
: superreview+
Details | Diff | Splinter Review
(Assignee)

Description

14 years ago
The security check added in bug 195201 blocks redirects to not only javascript:
urls but also data: urls; there is no clear reason given for this (in the code,
the checkin comment, or bug 195201 itself)... Filing this bug to get that looked
at and either comment the code to explain the check or remove the data: check.

You can test the redirect-blocking at
http://software.hixie.ch/utilities/cgi/data/data

Comment 1

14 years ago
hmm, yeah.. any javascript embedded in a data: URL shouldn't be able to execute
when loaded via a <IMG> tag, so blocking data: URLs from HTTP redirects should
not have been necessary to fix that bug.  or, maybe i'm overlooking something??
Depends on: 195201

Comment 2

14 years ago
If you allow redirects to data: URLs, you have to make sure that data:text/html
files loaded through redirects run with correct (or no) privileges.

Comment 3

14 years ago
wouldn't it make sense for a data: URI, resulting from a server side redirect,
to have the privileges of the original URI?  although i'm not sure that is even
a requirement for this bug.

Comment 4

14 years ago
The privs of the data: URL should be the same as the last redirecting URL (not
the page that originally linked to the URL).  I think this is the opposite of
what happens with referers.

Comment 5

14 years ago
jesse: yup, actually that was what i was thinking.. just wasn't what i wrote :-/

it should be easy enough to transfer the nsIPrincipal from the old channel to
the new channel in this case.  i'm just not sure where we would want that to
live at the moment.  perhaps in the HTTP code; however, necko isn't supposed to
have to know about these things.  there are plans to make necko not depend on
caps, and that would involve having caps hook in as an observer of redirects, so
maybe if that happens caps could easily at that time set the principal for the
new channel based on the old one if appropriate.  hmmm...
(Assignee)

Comment 6

14 years ago
caillon, any ideas here?
(Assignee)

Comment 7

13 years ago
*** Bug 253320 has been marked as a duplicate of this bug. ***

Comment 8

12 years ago
Bug 195201's fix made simple server-side redirectors not be vulnerable to XSS attacks.  To be consistent with that security goal, pages generated from data: URIs loaded through redirects would have to have their own principal (equal to itself, but not able to e.g. see the cookie from the site that did the redirect).
(Assignee)

Comment 9

12 years ago
You mean the problem that worries you is that I (site A) load data from site B and site B does a server-side redirect to a data: URI, which should then get the principals of B, not A?

That seems reasonable and not that hard to do.  Can you set up a testcase somewhere?

Comment 10

12 years ago
Not quite.  Giving it the principals of B is also somewhat dangerous, because there are many server-side redirectors that don't check what protocol they're redirecting to (and probably many that disallow redirects to "javascript:" but don't disallow redirects to "data:").  That's why I suggested not giving it the principals of A or B, but its own non-URL-based principal.
Just out of interest, is there a way for a site to make a data: URI have no rights at all? e.g. in the case I care about, the data: URI kitchen, I'm letting people create arbitrary data: URIs. I don't really want them to have the permissions of software.hixie.ch, I want them to have no permissions at all -- as if they'd typed that data: URI themselves, in the location bar.
(Assignee)

Comment 12

12 years ago
(In reply to comment #10)
> Not quite.  Giving it the principals of B is also somewhat dangerous

So the point is that some sites accept the URI to redirect to in the request?  And then just do it?  <sigh>...

Either way, that should be doable without too much trouble.  Can someone set up a testcase so I can test once I think I have a patch?
The CGI script in the URL field lets you create any random data: URI and will then redirect to it.
(Assignee)

Comment 14

12 years ago
Ah, excellent.  Jesse, what's a scenario you're worried about?  Want to data:-URLize it?
(Assignee)

Comment 15

12 years ago
So I just checked.  If we just allow redirects to data: URIs it should Just Work.  That is, the post-redirect document will have the URI principal for the data: URI.  Which means it will not be same-origin for either the original page nor the HTTP server that redirected to it.

So what's the problem with just allowing them, exactly?
(Assignee)

Comment 16

12 years ago
Created attachment 209302 [details] [diff] [review]
Patch to fix

I've verified (by stepping through the process in a debugger, though this is also possible to verify via code inspection) that the new document gets a principal based on the data: URI.  This means that it will be same-origin with any other data: URI that has the exact same data and wasn't loaded directly from a web page.  Which seems reasonable to me, frankly.

In particular, given a server-side redirector at site B and given a site at site A that uses the redirector, the data: document will have the principals of neither A nor B, as desired.
Attachment #209302 - Flags: superreview?(darin)
Attachment #209302 - Flags: review?(jruderman)
(Assignee)

Updated

12 years ago
Assignee: dougt → bzbarsky
Priority: -- → P1
Summary: Can't redirect to data: urls → [FIX] Can't redirect to data: urls
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Updated

12 years ago
Attachment #209302 - Flags: review?(dveditz)

Updated

12 years ago
Attachment #209302 - Flags: superreview?(darin) → superreview+

Comment 17

12 years ago
Comment on attachment 209302 [details] [diff] [review]
Patch to fix

Sounds good (not a code review).

I think the data: URL that come from nowhere should get a principal that is only equal to itself (by pointer comparison), but that can be discussed elsewhere.
Attachment #209302 - Flags: review?(jruderman) → review+
Comment on attachment 209302 [details] [diff] [review]
Patch to fix

I've tested it and seems safe (safer than clicking the data url in hixie's "your browser is broken" page!).

r=dveditz
Attachment #209302 - Flags: review?(dveditz) → review+
It's a minor thing, but should this be fixed for 1.8.1? Looks like the patch would be in nsHttpChannel.cpp instead because bug 248052 is trunk-only.
(Assignee)

Comment 20

11 years ago
Fixed.  Filed bug 334407 for the data: thing.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 786275
You need to log in before you can comment on or make changes to this bug.