Closed Bug 568410 Opened 13 years ago Closed 3 years ago

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

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking1.9.2 --- -
status1.9.2 --- wanted

People

(Reporter: masa141421356, Unassigned)

Details

(Keywords: sec-moderate, Whiteboard: [sg:moderate spoof])

Attachments

(1 file)

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.
Reproduced : Opening link in "New tab"
Not reproduced : Opening link in "Same tab" or "New window"
PLEASE mark this bug as "Security Sensitive".
This bug is also reproduced on Fx3.6.3.
blocking1.9.2: --- → ?
Component: Location Bar → General
Product: Firefox → Core
QA Contact: location.bar → general
Summary: [regression]URL spoofing using bidi (only Trunk) → URL spoofing using bidi when openning URL in new tab
Version: Trunk → 1.9.2 Branch
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>
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?
Group: core-security
Attached file Testcase
Whiteboard: [sg:moderate spoof]
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]".
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.
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
Product: Core → Firefox
QA Contact: general → general
Summary: URL spoofing using bidi when openning URL in new tab → URL spoofing using bidi when opening URL in new tab
Version: 1.9.2 Branch → Trunk
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...
(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/
This wouldn't block a release, but we would take a patch on the branches if there is one.
blocking1.9.2: ? → -
(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.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Group: core-security
Summary: URL spoofing using bidi when opening URL in new tab → URL spoofing using bidi when opening error page in a new tab
Assignee: bmcbride → nobody
Status: ASSIGNED → NEW

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

Flags: needinfo?(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.)

Flags: needinfo?(jfkthame)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.