123293 - wyciwyg://0/* urls sent as referrers after document.write

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Niels Aufbau]

Steps to reproduce:
1. Install linked images from
http://mywebpage.netscape.com/aufbau01/modifications.html.
2. Go to http://http://www13.smutserver.com/asian/tokyo/hard01/enime.html.
3. Use linked images.

Expected result: 
* Thumbnails and full-sized images appear in a new window.

Actual Result: 
* Only the thumbnails appear in the new window.

Problem occurs with: 
* 2002020103, 2002020103 (latest)

Problem does not occur with:
* 2002013103, Internet Explorer

Because of this bug, I cannot recommend current nightlies to Pornzilla users. 
Should I make it a blocker?

Comment 1

[neeti]

imagelib

Comment 2

[Ben Bucksch (:BenB)]

Neils, what is a "wyciwyg urls" (or wysiwyg urls)?
Please attach a reduced testcase.

Comment 3

[Ben Bucksch (:BenB)]

Dup of bug 122668?

Comment 4

[Alan]

google is your friend
wycwig stands for: What You Code Is What You Get

wysywig            ...      See is  ...
http://developer.netscape.com/support/faqs/champions/javascript.html#2-8

And it is used to keep track pages that the client generated or modified
using code (ie javascript).
For example using javscript to reconstruct a page to show just the images.

Comment 5

[Stuart Parmenter]

dup

*** This bug has been marked as a duplicate of 122668 ***

Comment 6

[Jesse Ruderman]

Not a dup.

Comment 7

[simon.hetzer]

Ok I think what we're requesting here is a way to fake the referer, sending the 
server name the image is located on as referer instead of the real referer or 
no referer at all. This should fix the porn browsing problems I think.
I'd also like to see a general "fake referer" toolbar but since I don't have to 
slightliest idea about coding I'm not the one to make requests.
Placing my vote ;)

Comment 8

[simon.hetzer]

after looking around for some time, maybe to all those who are interested in 
this bug, read through bug 55477 - afai can tell, Jeff Thieleke added a 
possible fix.
Sorry for the spam!

Comment 9

[Jesse Ruderman]

To test this bug, get a local web server such as OmniHTTPd (for Windows).  Place
the HTML below in a file called http://localhost/refer/index.html.  Load
http://localhost/refer/ in Mozilla and then click "foo".  You will see 404
requests for both the image and the link with the referrer
http://localhost/refer/, as expected.

Then click "rewrite this document", which document.writes the innerHTML of the
document, and click "foo" again.  You will see
wyciwyg://0/http://localhost/refer/ as the referrer for both the link and the
image.  The referrer should be http://localhost/refer/.

<a href="link">foo</a>
<img src="image" alt="[image]">
<a href="javascript:document.write(document.body.innerHTML + ' rewritten'); 
document.close();">rewrite this document</a>

In case it's not clear, this bug has nothing to do with faking referrers.  This
bug is about not exposing internal wyciwyg URLs to the Web.  See also bug 125003
(already fixed) and bug 148465.

Comment 10

[Keyser Sose]

*** Bug 148268 has been marked as a duplicate of this bug. ***

Comment 11

[Jesse Ruderman]

Attachment: patch

Comment 12

[Jesse Ruderman]

Attachment: patch with changes suggested by bbaetz

More failure checking, fewer nested ifs.

Comment 13

[Bradley Baetz (:bbaetz)]

Comment on attachment 91266 [details] [diff] [review]
patch with changes suggested by bbaetz

r=bbaetz

Comment 14

[Jesse Ruderman]

Taking, since I have a patch.

Comment 15

[Radha on family leave (not reading bugmail)]

The url is not necessarily restricted to 3 digits of numbers after the scheme
name. The number represents the session count of the document.write() done by a
document. In the real world, though it sounds far-fetched to have  a document
generate more than 1000 document.write() in its lifetime, one can easily create
a testcase just to make this bug regress. The wyciwyg session count used in the
url is a PRUint32. I think the patch should get pass all the digits instead of
just 3 to access the referrer.

Comment 16

[Jesse Ruderman]

Radha: That's what
+ // Path is something like "//123/http://foo/bar".
+ // Search path for a '/', starting at the third character.
+ PRUint32 slashIndex = path.FindChar('/', 2);
does :)  I tested the patch with wysiwyg URLs containing 1 and 2 digits.  

I can change the comments to
// Path is of the form "//123/http://foo/bar", with a variable number of digits.
// To figure out where the "real" URL starts, search path for a '/', starting at 
// the third character.

Comment 17

[Jesse Ruderman]

*** Bug 161185 has been marked as a duplicate of this bug. ***

Comment 18

[Darin Fisher]

Comment on attachment 91266 [details] [diff] [review]
patch with changes suggested by bbaetz

yuck... i don't think necko should know about wyciwyg URLs.  i know we have a
black list of protocol types that cannot send referrers, but eventually i was
going to replace that with a flag on the corresponding nsIProtocolHandler to
make things very pluggable and generic.

in short, can't docshell or some other layer higher up do this transformation
instead??

Comment 19

[Darin Fisher]

or, are there too many different places where wyciwyg URLs get set as referrers?

Comment 20

[Radha on family leave (not reading bugmail)]

DocShell does set the referrer on the httpChannel. I was thinking, I could take
care of wyciwyg in docshell.

Comment 21

[Darin Fisher]

Comment on attachment 91266 [details] [diff] [review]
patch with changes suggested by bbaetz

sr=darin

i talked with jesse about this for a bit, and i'm okay with this patch (for
now) since it fixes a security hole, but in the future i'd like to look into
factoring this code outside of necko.  necko should not have so much
information about external protocols.

Comment 22

[Jesse Ruderman]

Fix checked in.

Comment 23

[Peter 'Rufus' Nelson]

verifying this fix (and going back to do some more...testing =)

Comment 24

[[e-mail]]

caillon, another case for nsIURIFixup wyciwyg: cleanup?

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

Necko should not depend on docshell.