1844915 - Arabic IDNs allow address bar spoofing

Status: RESOLVED DUPLICATE of bug 1690979

(Firefox :: Address Bar, defect)

Description

[Bruce]

I have discovered a bug in the current Firefox client which may allow bad actors to impersonate legitimate websites. This testing was conducted using Firefox 115.0.2 64-bit on MacOS Ventura 13.4.

This bug occurs when rendering the text in the address bar and requires the URL and website to comply with the following:

1. The domain name must be an IDN and contain only scripts written from right to left (including the TLD)
2. No SSL certificate can be installed on the abusive website
3. The first character in the URL path must be a number
4. The impersonated domain name follows after the number

Numbers are treated as neutral in terms of script direction. As a result, the text renderer appears to get confused and moves the end of the URL path to the front. Thus the impersonated domain appears where the domain name should be. This seems to work with any arrangement of letters as long as the above rules are followed. Below are some examples using a test domain I have registered. I will write them in punycode for the sake of convenience.

xn--mgbbnu6gnz.xn--ngbc5azd/2023/07/21/www.whitehouse.gov/briefing-room/statements-releases

xn--mgbbnu6gnz.xn--ngbc5azd/101domain.com

xn--mgbbnu6gnz.xn--ngbc5azd/404/www.mozilla.org/en-US

I believe this is of great concern and is ripe for abuse by scammers and those wishing to spread misinformation. It would be especially damaging if the attackers specifically targeted users of the Firefox browser, redirecting Chromium based browsers and web crawlers to the actual websites. On somewhere like Twitter, which relies both on web crawling and a URL shorter, this could get really messy.

Comment 1

[Daniel Veditz [:dveditz]]

Despite the recently-fixed bug 1704420 I can reproduce this in Nightly (117) on Mac

Results are different depending on the setting of the browser.urlbar.trimURLs pref. The examples above assume the default setting of true and are more "spoofy" that way, but even when set to false we've messed up the order and you could construct a spoof. The middle example is especially odd when the setting is false because we break the "101domain.com" path segment and put the number in front and the rest at the end. Here is what the addressbar looks like with the two settings:

default: 101domain.com/بيلانجر.شبكة
trim false: http://بيلانجر.شبكة/101domain.com

What did we fix in bug 1704420? With the default trimming the testcase filed with the bug is still wrong; it is only fixed with the non-default "no trimming" case.

The number issue looks like still-unfixed bug 1690979; is this a dupe? from bug 1690979 comment 8

To further improve the situation we plan to introduce a direction character when we remove the protocol (bug 1833091). There may still need to be further work after that.

That bug landed in 116 so I guess we do indeed need additional work.

Comment 2

[Marc Seibert (:mseibert)]

In bug 1704420 we only fixed the highlighting of the domain. As far as I can tell from the examples the highlighting works correctly.

In bug 1836962 we are planning to insert a LTR marker when a protocol is trimmed. This should fix the above cases as well.

Comment 3

[Marco Bonardo [:mak]]

(In reply to Daniel Veditz [:dveditz] from comment #1)

Despite the recently-fixed bug 1704420 I can reproduce this in Nightly (117) on Mac

As Marc said, we have fixed domain highlighting, that has been considered sufficient (not optimal of course) for this set of confusing RTL cases.
Any part that is not the origin gets de-emphasized.

We're still working on better solutions when the protocol is trimmed, but that is proving tricky because of potential users regressions.
I don't think there's anything here that was not already known in bug 1704420 or bug 1690979.

The number issue looks like still-unfixed bug 1690979; is this a dupe?

Yes, it is.

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to Marco Bonardo [:mak] from comment #3)

As Marc said, we have fixed domain highlighting, that has been considered sufficient (not optimal of course) for this set of confusing RTL cases.

It looks like domain highlighting depends on lightweight theme. I was not seeing that fix with my current theme (Have a Fox Dream), but since the urlbar looked like the normal light-theme colors I didn't think about that possibility. Agreed, it looks much better with our default dark/light/alpenglow themes or in fact most themes I tried.

Not seeing that fix led to me misinterpreting what part of this issue was fixed in bug 1704420.

Thanks!

Comment 5

[Marco Bonardo [:mak]]

(In reply to Daniel Veditz [:dveditz] from comment #4)

It looks like domain highlighting depends on lightweight theme.

Thanks, I'm filing a bug about that, this is a functionality that themes should not be able to overcome, if possible.

Comment 6

[Tom Ritter [:tjr]]

bounty- as this is a duplicate of issues already on file.