568410 - URL spoofing using bidi when opening error page in a new tab

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Masahiro YAMADA]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100526 Minefield/3.7a5pre (.NET CLR 3.5.30729)

Steps to reproduce:
1. Write html that contains following "A" element.
   <a href="http://123456&#x202e;www.example.com">domain</a>
2.Click the link
3.Error page will shown.
4.Read URL shown in location bar

Expected result:
  It is "http://123456%e2%80%aewww.example.com/" (RLO is encoded)
Actual result:
  It looks as "http://123456/moc.elpmaxe.www" (RLO is NOT encoded)

This is not reproduced on Firefox 3.6.3.

Comment 1

[Masahiro YAMADA]

Reproduced : Opening link in "New tab"
Not reproduced : Opening link in "Same tab" or "New window"

Comment 2

[Masahiro YAMADA]

PLEASE mark this bug as "Security Sensitive".
This bug is also reproduced on Fx3.6.3.

Comment 3

[Masahiro YAMADA]

When using following link, problem is not reproduced.
(It shows search result of google, not error page)
<a href="http://www.google.com?q=123456&#x202e;www.example.com">query</a>

Comment 4

[Boris Zbarsky [:bzbarsky]]

I just tried following the steps to reproduce using:

  data:text/html,<a href="http://123456&#x202e;www.example.com">domain</a>

On both m-c and 3.6 I get the %-encoded string in the url bar.  Can you point to a page that would actually show the problem?

Comment 5

[Masahiro YAMADA]

Attachment: Testcase

Comment 6

[Masahiro YAMADA]

This problem is reproduced only when opening link in "NEW TAB".
And, this problem seems to be reproduced only when bidi character is used in
host name.

This problem can be used to make faked saver access error.

For example, first link in attachment 447699 [details] is link to www.mozilla.com[RLO].,
not www.mozilla.com., it is impossible to find difference in error page
between error of "www.mozilla.com" and "www.mozilla.com[RLO]".

Comment 7

[Masahiro YAMADA]

I wrote test code in URIBarSetURI in browser.js:
---------------
function URLBarSetURI(aURI, aValid) {
  var s = "gBrowser=" + gBrowser;
  if (gBrowser) {s = s + "\n.userTypedValue=" + gBrowser.userTypedValue;}
  alert(s);
---------------
When openning link in tab,
gBrowser.userTypedValue is not null (it contains non-encoded bidi).
URLBarSetURI encodes bidi using losslessDecodeURI() bidi only when gBrowser.userTypedValue is null.

Comment 8

[Masahiro YAMADA]

This problem is also reproduced in following steps:
1.open testcase
2.Copy link URL in testcase.
3.navigate current tab to about:blank
4.paste URL to location bar and go

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Presumably this is because addTab sets userTypedValue, and the error page doesn't clear it (since there's no onLocationChange?), so the userTypedValue gets displayed as-is forever. Assuming that's all right, there's no way to have this happen when an actual page loads, since the onLocationChange will update the value accordingly in that case...

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #9)
> Presumably this is because addTab sets userTypedValue

This should probably be http://www.mozilla.com%E2%80%AE/, though, rather than http://www.mozilla.com/

Comment 11

[LegNeato]

This wouldn't block a release, but we would take a patch on the branches if there is one.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #9)
> Assuming that's all right, there's no way to have
> this happen when an actual page loads, since the onLocationChange will update
> the value accordingly in that case...

Given that, I don't think we'd want to bother taking this on branches at all. We should probably also open this bug.

Comment 13

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Dan and I can't repro this, and we think it's fixed, do you think we can close it?

Comment 14

[Jonathan Kew [:jfkthame]]

Agreed, this doesn't seem to reproduce any longer. (I get punycode in the error page when I try the examples given, which seems like the correct result.)