1633225 - lock icon in URL leading to Spoof-able lock.

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Anonymous]

Attachment: Spoofing.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36

Steps to reproduce:

http://127.0.0.1/%D8%A7https://%F0%9F%94%92%F0%9D%90%AC%F0%9D%90%9E%F0%9D%90%9C%F0%9D%90%AE%F0%9D%90%AB%F0%9D%90%9E.%F0%9D%90%9B%F0%9D%90%9A%F0%9D%90%A7%F0%9D%90%A4%F0%9D%90%A8%F0%9D%90%9F%F0%9D%90%9A%F0%9D%90%A6%F0%9D%90%9E%F0%9D%90%AB%F0%9D%90%A2%F0%9D%90%9C%F0%9D%90%9A.%F0%9D%90%9C%F0%9D%90%A8%F0%9D%90%A6/login/enroll/entry/olbEnroll.go?.jpg

Actual results:

lock icon shown as it.

Expected results:

lock icon should be encoded since Spoofing due to RTL Mishandling is really a messy area.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

it looks like another case from the same root problem of weak domain, and likely another set of chars we may evaluate to not decode.
I seem to recall a quite old bug about these lock icons in the urlbar by memory, but bug search doesn't help me.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I think we already avoid those in idn domains, also see https://bugzilla.mozilla.org/show_bug.cgi?id=1629506#c3

Everything in 1F50F, 1F510, 1F512, 1F513 is confusable with a lock.
It's probably time we update the list of confusables in losslessDecodeURI as safety precaution, even if after the fix for bug 1623888 it will just be in the path.

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Apart from locks: U+1F50F, U+1F510, U+1F512, U+1F513
I'd also evaluate adding shield, because of our UI: U+1F6E1

Additionally, comparing our list of ignorable chars in losslessDecodeURI with http://www.unicode.org/L2/L2002/02368-default-ignorable.pdf we are missing: 06DD, 070F, 180E, FFF9, FFFA, FFFB. I'd be prone to add them unless there's reasons not to.

Chrome additionally also considers ignorable these chars: 0600-0605, 08E2, 110BD, 110CD, 13430-13438, 1BCA0-1BCA3. I couldn't find a reference in unicode stating these should be ignored, thud I'd be prone to not add them for now.

Jonathan, wdyt?

Comment 4

[Jonathan Kew [:jfkthame]]

U+06DD is a control that's supposed to combine specially with (Arabic) digits, but is unlikely to render well in any except specialized fonts. Trying to render it in a URL is probably not going to end well, so encoding it seems fine.

Similarly, U+070F needs special font handling, and without that, it may not render usefully.

U+180E is likely to be invisible; I see we already list U+180B..180D, so makes sense to include this as well.

I'm not sure anyone actually uses/supports U+FFF9..FFFB in any useful way.

So yes, I'd agree with encoding all these.

As for the Chrome additions: they seem to be all controls (category Cf) that would require advanced font support of some kind in order to render usefully. It's unlikely they'll work "correctly" in a default system UI font such as we expect to see in the URL bar, and they might fail to render at all if unsupported. So it's probably sensible to encode these as well, rather than just leaving it up to the system font to do whatever it can with them.

(Is it basically a case of encoding all characters with General Category = Cf?)

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Jonathan Kew (:jfkthame) from comment #4)

(Is it basically a case of encoding all characters with General Category = Cf?)

That's apparently what Chrome is doing, though we already made exceptions for U+200C and U+200D in the path per bug 582186.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: Bug 1633225 - r=jfkthame

Comment 7

[Daniel Veditz [:dveditz]]

I tried to make bug 1629506 into the general case, pointing out the lock-ish characters--and others!--in bug 1629506 comment 2 links to the Chrome list.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

I tried to make bug 1629506 into the general case, pointing out the lock-ish characters--and others!--in bug 1629506 comment 2 links to the Chrome list.

That is where I started investigating the general support, so thanks!

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/554dcd35c9e0d2f43b8050415afb283da34dde8c
https://hg.mozilla.org/mozilla-central/rev/554dcd35c9e0

Comment 11

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I verified this issue using Fx 77.0b7, on Windows 10 x64, macOS 10.13.6 and Ubuntu 18.04 LTS,

Comment 12

[Daniel Veditz [:dveditz]]

Bounty combined with bug 1623888 since that's required to make this at all plausible.